[squeak-dev] DoIts in Deltas - give us feedback please
Göran Krampe
goran at krampe.se
Tue Sep 8 19:15:01 UTC 2009
Hi!
Juan Vuletich wrote:
> 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.
Yes, I agree. If Deltas don't end up being 100% a superset of Changeset
then we will have a problem.
>> 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!
Right, I agree.
>> 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.
Right. The approach above is to force people to "think" about what a
reverse doit needs to do. Today the implementation of asAntiChange
simply swaps the doIt and the antiDoIt source. So if the reverse should
just "run the same code again" - then you supply the exact same code as
the antiDoIt - we do not presume that as a default case. Again, forcing
the developer to be explicit in order to be on the "safe side".
>> 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.
Yeah... Splitting the "parts" between the doits into atoms is not hard
in SystemEditor. So yeah, we need to decide to do that - or to not
support "in between doits".
>> 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!
Good.
>> 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).
Ok, then I perhaps misread the code the first time. So if I add a class
var in a class it does NOT add an initializer? Ehrm.
> 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
Yes, intuitively it feels like they should be run after...
- class var changes (obviously)
- a changed or added #initialize method. (obviously)
- class ivar changes ...
ehm... darnit I need to read up on class initialization...
> b- They are not dangerous
Should not be :)
> c- They can be applied multiple times
Should be :)
> d- Their reverse is just to evaluate them again after undoing the
> changes (or doing nothing if the class doesn't exist anymore)
Right.
> 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.
Which implies we do NOT represent these calls as DSChanges, right? Just
put the logic into the applier?
> This all looks really great. I guess I'll be trying DS in Cuis pretty soon.
:)
regards, Göran
More information about the Squeak-dev
mailing list
|