Hi!

Andreas Raab wrote:
> Göran Krampe wrote:
>> Mmm, my point was probably that if you set a Delta to record doIts and 
>> then just file it out without looking at it you will be bringing lots 
>> of garbage along...
> 
> Well, then don't do that! ;-) No, seriously, what is the use case for 
> setting a DS for recording doIts? Are you trying to replace the changes 
> file as well? I can see how this might be appealing but I think that's 
> bit of a distraction at this point. What the (Squeak) world needs isn't 
> really a better changes file. What it needs is a better change set 
> mechanism. I think that by not recording doIts by default you're not 
> loosing any value in the near term and you are avoiding issues that you 
> may not be ready to address yet.

I am all with ya, and it will not be set to true per default. :) So 
that's fine.

>> 1. If we record doIts they are NOT marked to executeOnApply. To 
>> prevent accidental replaying of a log. You can then use the UI, select 
>> such a doIt and just use a menu choice to mark it as executeOnApply if 
>> you like to.
> 
> See above. I would just say that for the time being you need to add 
> doIts explicitly, they don't get recorded. Just like change sets. It's a 
> simple model that people already understand.

Sure, it will be false per default :)

>> 2. If you *add* a doIt using the UI for Deltas (which probably will be 
>> the reasonable way to add doIts anyway, just like with 
>> preamble/postscripts today) then the default will be executeOnApply = 
>> true. A second pane will be available for the antiDoit.
> 
> Sounds good.
> 
>> 3. Skip the warning on distribution, better to make sure the UI shows 
>> that a Delta includes doIts that has executeOnApply = true. Fair?
> 
> Sounds good.
> 
>> 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?
- Do we only trigger it by touching the method? What about shape 
changes? (as in changed class vars, pools (?) or class ivars)

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

regards, Göran