Hi! (not up to speed on Pharo "goals" in this area, but...) On 10/22/2012 09:45 AM, Goubier Thierry wrote:
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...).
Note - Deltas actually *exist* - it is not just a proposal. They work. And the answer is "yes", it enables full multilevel undo of *source* changes to the image. It does this by making sure each "Change": - Has captured enough state to reverse itself in full. - Knows how to create its "anti-Change". ...then the code in Delta>>undo basically ends up like: changes reversed do: [:each | each asAntiChange apply ] ...well, in fact - it is not written exactly like that - we create a full "anti-Delta" first, and then "apply" it. But anyway, you get my point. Major changes compared to the total misfit ChangeSet: - A Delta has *ordered* Changes, not a "Set". So we could call a Delta a "ChangeList" instead. :) - A Delta and its list of Changes is *completely* standalone from the rest of the image. Thus trivially serialized, thrown away etc. A ChangeSet is *not at all* standalone, which is the worst aspect of them. You can easily see this yourself by: - Create a ChangeSet and add a method (it gets recorded) - Create a new ChangeSet and modify same method (it gets recorded in the new ChangeSet) - Take a look in the previous ChangeSet, tada! The method there is now not at all what it was from the start... ...so a ChangeSet actually only "points" at methods, they do NOT contain the actual change! Now, coming back to Change>>asAntiChange - this is where the tricky part starts... First each SystemChangeAnnoncement MUST capture all state. For example, earlier a "new class comment" didn't send along the old comment! And it was fired *after* the change was done, so information was lost. Not sure how Pharo does on that exact example today - worth checking for fun! :) Secondly, the delete/remove Change objects end up to have to capture ALL state that was removed... So a "remove class X"-change must in fact capture enough information to be able to reconstruct it. Thus Deltas have CompositeChange which basically is a full list of smaller changes like create a class X, add n methods to it etc.
How does this relates with the undo/redo facility in RefactoringBrowser?
Dunno.
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.
IMHO they are in fact two different things - but of course can be made to play better with each other. Also, one reason ChangeSets are hard is probably because they are misunderstood (because of their bad design IMHO). Sorry for lengthy post. regards, Göran PS. I presented and demoed Deltas at an ESUG a few years back, but unfortunately most people attended a Seaside thing in parallell :)