Hi all, I'd like to ask if I understood correctly this part of the discussion. With a suitable log/change format as Deltas propose and Igor is thinking of implementing, we could undo any changes done on the image (such as method creation, modification, class add/remove, etc...). How does this relates with the undo/redo facility in RefactoringBrowser? And a question which is nagging me regularly when I try to get my head around it: could we unify change sets and packages? I'm just regularly lost when I try to play with the change set tools. Thierry Le 22/10/2012 00:23, Göran Krampe a écrit :
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.
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.
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)
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.
regards, Göran
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95