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

Juan Vuletich juan at jvuletich.org
Tue Sep 8 14:11:00 UTC 2009


Hi Göran,

Göran Krampe wrote:
> 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.

Sure.

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

I really want to replace ChangeSets in Cuis. I don't want 2 mechanisms 
for doing almost the same. Being able to remove ChangeSets is a must for me.

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

That's ok. The auto-prunning is not needed. If you log the doits, it is 
because you want to face those tons of crap!

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

This is ok if class initialization is not done by a DSDoIt but, as you 
suggest at the end, by a special mechanism.

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

If you support DoIts in the middle of the Delta, you also need to apply 
the first part (perhaps atomically), then the DoIt, then the second part 
(perhaps atomically). If this involves any complexity, then just only 
handle DoIts at the ends of Deltas.

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

Sounds great!

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

Don't worry about that. If you're recording DoIts, you already have tons 
of crap anyway.

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

The most needed use of DoIts and postscripts is indeed class 
initialization. ChangeSets add the doIt only if the #initialize method 
is modified (at least in Cuis). I believe these DoIts have these properties:

a- They can be created automatically, if the #initialize method changes, 
or (as you say) if the shape changes
b- They are not dangerous
c- They can be applied multiple times
d- Their reverse is just to evaluate them again after undoing the 
changes (or doing nothing if the class doesn't exist anymore)

I think calling #initialize automatically on apply (and unapply) is ok. 
There is a little risk, but not much bigger than being able to modify 
any method in the system.

This all looks really great. I guess I'll be trying DS in Cuis pretty soon.

Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list