On Oct 19, 2004, at 4:00 PM, John Pierce wrote:
>
> 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.
>
> I guess equality between classes could be defined as their instVars
> (shape of class) are identical (or compatible).  I'd also probably
> include comparison of the method dictionaries in my definition of
> equality and if behavior has changed then the classes are no longer
> equal.
>
> At this point I am less concerned about exact definition of equality
> here -- it could be a loading strategy applied by the developer in a
> specific situation that suits his purposes.
>
> Anyways, I have this notion in my head that *not* having to migrate
> instances of objects every time we change classes could be a very
> enabling development mode to be in.

This is interesting, but it would only be useful in a very specific 
case: where the implementation (to the level of the class format) 
changed, but the interface didn't.  If the class format didn't change, 
there's no real benefit, and I think it's going to be a lot more 
maintainable to have all your instances using the same version of the 
code.  If the interface changed, you're going to have DNUs or broken 
invariants by using an old version of the class, and you'd be better to 
migrate forward.  So you're going to have to be explicit about marking 
which few class modifications are actually acceptable to be treated 
that way - and at that point, maybe the simplest thing is just to copy 
and rename the class first?  The old instances will use the old name 
and thus the old class, the new instances will use the new class.  If 
you wanted, you could rename the old class instead of the new one, and 
use the database's server-side migration tools to change all Foo 
instances to FooOld instances, for example.

It's not that it's infeasible to store the actual class in the DB - it 
could certainly be done.  But I'm not sure it's the most maintainable 
approach.

Hopefully someone will chime in here and explain how Gemstone deals 
with all of this...

Avi