On Oct 19, 2004, at 12:13 PM, Cees de Groot wrote:

> On Mon, 18 Oct 2004 20:44:40 -0700 (PDT), Chris Muller 
> <afunkyobject at yahoo.com> wrote:
>
>> But while working on Magma 1.0gamma8, the primary improvement of 
>> which is live
>> class-evolution, I decided to get rid of the upgradeBlocks entirely.
>
> Ditto with OmniBase. We provide for compatibility often by adding some 
> code in the getter ('if value is something old then convert 
> on-the-fly'), in 'heavy' cases we provide code in the deserializer and 
> often we even convert the whole db between versions by keeping track 
> of what needs to be done and then simply reading/writing all affected 
> objects.
>
> Bottom line is that 'nil' is the correct general-purpose answer that 
> the DB should provide you, and what you want to do beyond that is all 
> implementable in straight Smalltalk.

The question is not so much what value to provide for a new instance 
variable when one is added, as what to do with the old data when one is 
removed.  If you follow the default Smalltalk behavior, then you lose 
that data, which doesn't seem like such a good idea.  So at the least 
I'd say you want some kind of interface where, on discovering a nil in 
one instvar, you can access a dictionary with lost field values so that 
you can do some conversion and properly fill it in.

But yes, of course it's all implementable in straight Smalltalk; who 
was suggesting anything different? :)

Avi