2009/12/25 Lukas Renggli <renggli at gmail.com>:
>> However, I think that a generalized framework for capturing state changes and applying them later is a Very Hard Problem. It might be possible if you implemented a new Smalltalk with transactional semantics like Gemstone: commit and abort operations, and a third operation to abort-but-create-a-change-set.
>
> In fact it is quite simple to do at the image level:
>
>    http://scg.unibe.ch/archive/papers/Reng08aTransMemory.pdf
>
> I haven't tested the implementation on installing code though. The
> problem is that this involves quite some primitives that need to be
> handled differently.
>

Thanks for the pointer, Lukas. Very nice alternative :)

This, however is a bit overkill, to my thinking, since inside a
transaction its going to capture all changes to any existing objects
regardless the intended scope.
While, if we talking about classes, our scope is tend to be small
(comparing to whole system) since we have to care about much less
things: method dictionary, organization, ivars etc etc.
For instance, if we would want to change a number of instance
variables for existing class inside transaction,
this will lead to recompiling the whole class and subclasses and
mutating all of existing instances, and inevitably, a transaction will
capture quite big number of objects.

While, if we define the scope: capture changes only to specific
object(s), while rest of the code will run normally (even if inside
transaction), this will be much more efficient.

This is what actually a SystemEditor does, but i want to find out a
simple way how we could make it without the need of creating a
separate layer which needs to mimic all the behavior of observed
object(s).

> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>

-- 
Best regards,
Igor Stasenko AKA sig.