Göran Krampe wrote:
>>> 4. Let the applier contain the class initialization logic. We do not 
>>> add any Changes specifically for that. And let's make it predictable. 
>>> I still would like to see a proposal for that logic. AFAICT it is a 
>>> bit tricksy, especially regarding class ivars and inherited class 
>>> side #initialize.
>>
>> I'd say that the general rules of thumb should be: Superclasses are 
>> initialized before subclasses. Otherwise initialization occurs 
>> strictly in alphabetical order. The applier probably needs to do that 
>> at the end of the application / reversal of the delta stream and 
>> should do it whenever the initialize method was touched.
> 
> Ah, ok, finally some proposed logic. :) Excuse me for being dumb here, but:
> - Do we only send initialize to classes that implement it?

Yes.

> - Do we only trigger it by touching the method? What about shape 
> changes? (as in changed class vars, pools (?) or class ivars)

Yes and No. Yes, when an initialize method is touched it should be 
called (this "trick" proved extremely useful in Monticello). No, class 
shape changes shouldn't trigger it (I think).

> I am presuming you have spent tons of more thought on this - that is why 
> I am picking your brain.

Actually, not too much. I'm mostly going by my experience with 
Monticello vs. change sets.

Cheers,
   - Andreas