> 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.

In the long run, yes, it will be more maintainable to keep all
instances on the same version of the class.  My point is that in the
short run it is generally a concern that creeps into my development
thoughts too soon.  I'd rather defer the migration issue until later
(like deployment time -- or even after deployment -- ah ha!).

> 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.

Yes, the old instances with old behavior might not plug into my
application and will probably give me the dreaded DNU when I try to
use them, but, at least they are live and functioning.  Then I can
break out a workspace to migrate them forward, as appropriate.

This could potentially be better than the auto-migration approaches of
SmartRefStream and/or GOODS client right now -- where it is a bit more
mysterious to me as to the hard and fast rules of upgrading instances.
 Some migrations cannot be done automatically and require explicit
migration by the developer and, even worse, some happen silently
without notifying the developer.

> So you're going to have to be explicit about marking
> which few class modifications are actually acceptable to be treated
> that way.

Well -- it could be implicit, right?  InstVars still the same?  Yes or
no?  Selectors still the same?  Yes or no?  Method bytecodes still the
same?  Yes or no?  Some combination of this could be used as
appropriate, right?

> - 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.

Yes, this is what we must do now.  I just wonder why I always have to
decide this upfront.  I mean, sometimes, I don't even remember that
there are instances of the class I am changing in the database.
Doooh.  Now it is time to backpedal and do the refactoring in smaller
steps and migrate instances more carefully.

> 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.

I could do that -- but I don't think the database migration tools feel
like Smalltalk to me.  I'd like to work in the same environment that I
grow these objects, if possible.  I know, I'm being difficult.

> 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.

I think mostly I would like it if it were an option.  Right now, it is
not an option so I must consider all the ramifications of my
refactorings to classes and their impact on stored instances in
advance.  Isn't it enough just to work out my next assignment without
being bothered with migration details at the same time?

I just think working this way only makes it an option to do migration
at my pace.  It's probably not a matter of *if* I will migrate, but
*when*.  I could even defer migration until after deployment and no
harm will be done except maybe some pink walkbacks that I won't
understand.  But at least, objects don't get auto-reshaped when loaded
and potentially corrupted.  And (this is important), I don't have to
do the refactoring steps like "keep the old class around" in my system
dictionary just on the off-chance that I still have some of those
stored instances around.

I just want to delegate some book-keeping to the stored environment if
I may.  Tell me to shutup now or I might go on about this forever.

Regards,

John

-- 
If at first the idea is not absurd, then there is no hope for it. --
Albert Einstein