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

Göran Krampe goran at krampe.se
Tue Sep 8 11:01:08 UTC 2009


Hi!

Ok, one of the things we did in Brest was to add first support for DoIts 
in Deltas. Up to now a recording DSDelta creates DSChange instances 
(subclasses thereof) for each kind of change.

This means we DO NOT create doits in Deltas for method removals, class 
creation nor class initialization (although that actually will cause 
code to be run that of course potentially could screw things up) etc. 
All these three are instead covered by different DSChange objects.

BUT... if we want to replace Changesets we need to support doits at 
least as much as Changesets do. A Changeset can have a preamble and a 
postscript with code in them. This means you can include an arbitrary 
snippet of code to be executed pre/post the install of the Changeset.

A Delta consists of an sequence of DSChanges. This means that we can put 
a DSDoIt anywhere in that list - even in the middle. Ok, so we are 
"better" than Changesets :)

BUT... a Delta is meant to be reversable etc, so by allowing doIts we 
are moving into undefined territory. Thus, the medicine looks like this:

1. We do NOT record doits by default. Changesets actually don't record 
doits either btw. :) But you can tell a DSDelta to record doits which of 
course will log tons of crap, but it can be interesting to log and then 
just prune it away. And yes, we could analyze the actual doits and do 
some auto-pruning but whatever...

2. If you record a DSDoIt OR add one manually it will NOT be executed 
when the Delta is applied! You need to EXPLICITLY mark it using 
executeOnApply: true.

3. If a Delta contains a DSDoIt marked to execute on apply, the Delta 
will be considered NON-reversable UNLESS you also supply an antiDoIt 
code snippet! In this case DSDelta>>isReversable would say "true" BUT 
this only means that it COULD PERHAPS be reversed.

Finally we will explicitly explain to the developer that:
--------------
If you still have a DoIt in your Delta that you intend to distribute, 
make sure that:
		- It can cope with missing globals/classes!
		- It can be safely run multiple times without problems!
		- You marked it to be run on apply using #executeOnApply:. This is an 
EXPLICIT step for a reason.
		- If it should do able to be REVERSED you need to supply an antiDoIt.
		- Put DoIts preferrably first or last in the Delta to avoid strange 
situations. Remember that even if changes are ordered they may be 
applied atomically by an applier.

NOTE: A Delta containing any DoIt will be visualized as "dangerous" in 
the user interfaces so please avoid them unless you REALLY need them.
-------------


Well, something like that. Does the above handling of DoIts seem 
reasonable? Any other suggestions or enhancements to all this?

Sidenote: If a Delta is set to record doits it will end up with *both* a 
class creation change and a class creation doit. As the code stands 
today the Delta can't tell the difference. I was inclined to perhaps use 
the #kind: selector in AbstractEvent to distinguish the doits produced 
by our own tools from doits performed by the developer himself in 
ParagraphEditor etc. But I dropped that for now. As described above such 
a recorded DoIt will not be executed on apply anyway - to be recording 
doits is mainly useful as a "true log" of everything happening.

regards, Göran

PS. Any interesting thoughts about class initalization is also 
appreciated. A Changeset slaps in an initialize-doit when being filedout 
if touched class definitions (I think) has such a selector. Should we do 
something similar on apply?




More information about the Squeak-dev mailing list