Hi guys!

Igor Stasenko wrote:
> 2009/9/10 Andreas Raab <andreas.raab at gmx.de>:
>> 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 think it is completely useless to put such trick(s) in design, because they
> a) do not cover 100% of different cases when something changed and
> requires class (re)initialization
> b) makes deltas less predictable (by introducing some fuzzy logic)
> which contradicts the design principles we are declared first and
> foremost :)
> 
> So, my point , that #initialize should be controlled by users
> explicitly without any automagic.
> 
>>> 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.

Ok, here is a suggestion:

- We add a Change object that is DSClassInitializationChange. So Igor is 
right in a sense, better to put the developer in full control. This 
change could just list a bunch of class names that it will send 
initialize to - in that order.

- Thus the developer can edit/add such a change as needed.

- And we add some predictable logic to cover 95% of the cases by auto 
creating such a change.

Given what Andreas said in the beginning about how class initialization 
should be handled on revert, perhaps it gets tricky. I need to read that 
again...

One definition of predictable logic could be:

- Trigger initialization by added or modified class side #initialize method.
- Make the sorting order be "least number of superclasses" first, class 
name second.

regards, Göran