[squeak-dev] Atomic updates & SystemEditor

Igor Stasenko siguctua at gmail.com
Fri Dec 25 01:39:27 UTC 2009


2009/12/24 Colin Putney <cputney at wiresong.ca>:
>
> On 2009-12-24, at 9:42 AM, Igor Stasenko wrote:
>
>> Hello guys,
>>
>> A SystemEditor is the only tool , currently existing, which allows us
>> to perform an atomic updates.
>> However, its having own shortages.
>> A SystemEditor mimics the Behavior/ClassDescription/Class protocol,
>> so any change you going to make to system is recorded , but not
>> applied immediately.
>>
>> This is good, but at same time, this is the main source of shortage,
>> because once you may want to change the Behavior protocol(s), or
>> extend it (see Traits), you gonna to change a SystemEditor as well to
>> mimic new behavior and new state, otherwise it wont work as expected.
>> Needless to say that, keeping two different parts of system
>> synchronized doubling the amount of work, as well as makes it brittle
>> and highly error prone.
>>
>> So, i asking the question, is it possible to implement a framework,
>> which would be able to:
>> a) capture changes to any object(s) of interest.
>> b) serialize/deserialize captured changes (to file out/in)
>> c) apply changes atomically
>
> Hi Igor,
>
> I agree with your assessment of SystemEditor - the design is inherently fragile, because it relies on one set of objects closely mimicking the behaviour another set of objects, but with a completely different implementation. It's definitely error-prone and the parts of SystemEditor that mimic the class-modification protocol are the ugliest.
>
> 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. Encoding the change set in such away that it was reasonably independent of the starting state and could be applied to a *different* starting state is an exercise I leave to the reader, but one can imagine that being free to play with the semantics of the programming language could make it feasible.
>

Let me clarify couple things: Of course i don't want to make it too
generic. I want to make it generic enough for capturing changes in
existing Class/Metaclass model. This may be hard , but i think it is
not Very Hard (an existance of SystemEditor is living proof of that).

> I think that trying to implement this against an existing system with lots of legacy code would be impossible. Every so often somebody runs up against some limitation of Monticello and wonders why we didn't just implement a generalized object versioning system. This is another framing of the same problem. I don't have the math or comp sci chops to prove it, but I bet it's one of those nature-of-computing issues. I suspect that solving this problem would require solving the halting problem, or proving that np=p or some similarly stupendous theoretical achievement.
>
> The approach we took with Monticello and SystemEditor was to cheat by limiting the domain to a certain set of objects with well-understood semantics, ie, the Smalltalk meta-objects: Classes, methods etc. There might be a better way to implement SystemEditor, make different engineering tradeoffs etc. I don't think there's a way to make it robust in the face of changes to the semantics of Smalltalk language, like Traits.
>

Smalltalk claims to be a self-descriptive language. And, since its
claims so, then it should be possible to observe what changes is going
to happen, if i evaluate some code (a Lukas paper is good illustration
to that).
So, then it is up to a software engineer to make it easy to describe a
system change along with the change itself.

This is what a SystemChangeNotifier, isn't?
And best way to ensure that description is in sync with actual
implementation is to make it live as close as possible (in same
method).
It is not automated (in contrast to transactions), but hand-crafted
observation of already made changes.
So, why we can't employ the same approach, but for not-yet made changes?


> Colin
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list