On 22 October 2012 00:23, Göran Krampe <goran@krampe.se> wrote:
Hi!
On 10/21/2012 11:46 PM, Igor Stasenko wrote:
To me the one of important part of this story is to have better code reuse. I like the idea of (re)using regular smalltalk parser to do heavylifting, while rest is built on top of it.
(I presume regarding external serialization format, anyway, you might note that having "full Smalltalk" is a security issue also, and a speed issue)
I like the idea with Deltas that you can rewind them or play them. Now the problem is that it will require substantial effort to adopt it to Pharo. Not long ago, we introduced SystemAnnouncer, and if you look at announces (SystemAnnouncement subclasses) you can see that it very closely resembling delta records.
I would suspect, yes. But still different since I presume a SystemAnnouncement does NOT capture enough to enable undo, so they are still "different beasts". Also, (without having looked) I guess a SystemAnnouncement is not a "standalone object" like a Change in Deltas is. I mean, it probably references the class, or a new method etc - and doesn't actually contain a full copy of all state of the actual change.
right, but if we would do it right, i would make it like you said. Instead of having parallel class hierarchies which representing same event(s) in system.
I dont think that it will be clever to have two classes per each system event, i.e. ClassRemoved and then ClassRemovedDelta. It would be much nicer to have a single one.
See above. Different responsibilities, right? But I agree with the "itch", not sure if it can be fully helped though.
Well, both Deltas and SystemAnnouncement reflecting the change in system. The only difference is that Delta has more capabilities than serving as a simple event. It would be nice if we could leave only single class hierachy for that (not two, parallel ones). Because same story again: once you have parallel stuff in two different places in system, it is prone to go out of sync sooner or later.
Another thing is what to do with SystemEditor? My main problem with it, that it is gone too far, trying to resemble many Class/Behavior protocols.
Personally I thought it looked "awful" - but I just wanted to be a user and get "atomicity". IMHO one should be able to get atomicity using become tricks instead, IIRC Henrik Gedenryd (bless his soul) did atomicity in his old 3.3modules code using such a trick (building new classes and then at end - do a "sweep become-replace" operation of all the modified classes)
right, but there's many pitfalls, like code which relying on new shape of a class, but not able to see it because it is still not installed. or opposite: the code which relies on old shape, but forced to 'speak' with new shape, where that part is removed/changed.
That means that any change/extension in Class/Behavior will have potential risk breaking SystemEditor, if we forget to sync changes there as well. And the last time we did pass on SystemEditor, if i remember, there was still no support for traits.
But sure thing, i should not forget to say about what SystemEditor gives: atomic updates. My only concern is that price for having such feature is a bit too high as to me: - big and complex (okay, non-trivial ;) ) logic - a maintenance needed if we go and hack Class/Behavior/Traits etc).
for the other features, i don't see significant advantage of using it over something else (less complex and more compact).
Final comment on SystemEditor - it is not hardwired into Deltas, in fact it is kept separate and the idea was to be able to have different "Applier" classes using different mechanisms.
Yes, personally i would like to see Deltas (modulo SystemEditor) integrated in pharo.. but the problem that who will make it happen :)
regards, Göran
-- Best regards, Igor Stasenko.