2009/6/30 Göran Krampe <goran at krampe.se>:
> Hi!
>
> Nicolas Cellier wrote:
>>
>> 2009/6/30 Göran Krampe <goran at krampe.se>:
>> Goran, this is great work I'd like to support.
>
> :) Thanks!
>
>> But I can only believe that it works in most cases...
>> More exactly, I suspect it works for code, but not on lively instances:
>> If I remove an inst var, all instances of the class and subclasses
>> will loose some information.
>> Do you store that information in the delta so that reversion restore the
>> state?
>
> Nope, we only deal with source. If you want image level kind of reversion
> then I can only recommend... image snapshots :). Or some kind of
> Gemstone-ish memory.
>
>> Otherwise, I know of some anti-refactoring that will kill my image nicely.
>>
>> If I remove a class, how will orphaned instances be restored?
>
> Again, we only deal with code. Like ChangeSets do.
>
>> Do DeltaStream address something like refactoring ScaledDecimal from
>> something like:
>> Number subclass: #ScaledDecimal instanceVariables: 'fraction precision'.
>> to:
>> Fraction subclass: #ScaledDecimal instanceVariables: 'precision'.
>>
>> This shit is real (MIT refactoring applied in Pharo) and requires some
>> other shit like:
>> Create class ScaledDecimalTemp
>> Mutate allInstances of ScaledDecimal to ScaledDecimalTemp
>> remove ScaledDecimal
>> rename ScaledDecimalTemp to ScaledDecimal
>>
>> I'm very interested how would you handle such mutation and
>> anti-mutation in DeltaStream?
>
> Ouch! :) Again, no, we have not looked at instance migration issues.
>
>> It's doable with user crafted pre/post scripts without system
>> validation... Is that the solution?
>
> You mean in Deltas? Well, a Delta is meant to be able to do everything a
> Changeset can - so we need to support scripts (it is just another change
> class called "DSDoit"). Since the changes are ordered the "doits" can appear
> not only before or after but in the middle too :).
>
> So... well, I presume "surgery" gets a tad simpler to do with Deltas since
> they simply record all the steps you perform. Thus, if you perform the steps
> you describe above - in sequence - then you have a DSDelta that will work.
> Slightly simpler than editing the Delta in order to add pre/post scripts
> etc.
>
> This also means that we typically want to "prune" doits from Deltas, since
> they are normally not really wanted.
>
> regards, Göran
>
>

Thanks, that's what I thought.
I just wanted to point out that in some cases, special doIts are necessary.
In theses cases, anti-delta generally won't work, and should better
not be attempted.
OK for me if tools cover 90%, atomic loading is just another example
not covering 100%.
Just think of providing enough hooks for the remaining 10% in the
overall process.
This kind of refactoring will likely happen to anyone touching
Process, Graphics, user interaction like Sensor, Compiler and other
Kernel beasts... That's not that rare. Ask Igor, Andreas, Eliot,
Michael, Marcus, etc...

Nicolas