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

Andreas Raab andreas.raab at gmx.de
Thu Sep 10 02:15:53 UTC 2009


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.

> 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.

> 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.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list