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