> On the other hand, when loading instances of Foo from the database at
> some point in the future, if Foo sub 1 no longer equals Foo in the
> System Dictionary, then Foo sub 1 is reconstituted (but not loaded in
> the global System Dictionary??) and the Foo instances become new
> instances of this nameless Foo sub 1 class.

Perhaps a clarification should be made by what is meant by "having to migrate
instances of objects every time we change classes".  In other words, is it
intrinsically or extrinsically required.

In the case of Magma 1.0gamma7 yes, you *have* to migrate because it doesn't
support live class migration and it won't let you connect to a database if your
class-shapes don't match the shapes it knows so it is intrinsicallly required. 
I agree with you that it is very enabling to not have to stop what you're doing
to change a class definition.

The new, upcoming version, changes this but, as Avi pointed out, you will most
likely not be able to ignore it in many cases for reasons extrinsic to the
database; e.g., your own program will probably start blowing up (DNU's) if
there are not well-formed instances.

Magma now stores multiple versions of class-definitions in the database, but
only one set of code.  But GemStone, from my memory, takes it one step further
and keeps the *code* with each version of the classes as well as their
definitions (shapes).  GemStone is actually its own Smalltalk that keeps its
own class definitions and actually allows you to run parts of your program code
on the server-side.

But in the three-years (two companies) in which I was priviledged to work with
it, nobody wanted to take on the complexity of having different versions of
objects and code running simultaneously in a production system.

I can totally understand this.  Imagine the headaches that could be created for
a production system if subtle differences between the code in versions of a
class caused "bad data" that went unnoticed for a long time.  Instead, they
tackled the migrations head-on.  Sure, during development, you could relax a
little, but part of the deployment process ensured one version of each class.

 - Chris