[squeak-dev] Re: DoIts in Deltas - give us feedback please

Igor Stasenko siguctua at gmail.com
Thu Sep 10 15:49:47 UTC 2009


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.
>
> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list