[squeak-dev] Re: DoIts in Deltas - give us feedback please
Göran Krampe
goran at krampe.se
Thu Sep 10 22:23:58 UTC 2009
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
More information about the Squeak-dev
mailing list
|