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