> The "main-effect" as you call it, is now becoming a side-effect of > adding the action to the composite action. What you've done in that > changeset is break the encapsulation, and screw up the contract of > UndoableAction.doAction().
You mean, "provide an alternative contract", I think. :) I might even go so far as "provide a more useful contract"... Writing actions in the future tense is hard. My first thought was to create a "ImmediateCompositeUndoableAction" class. But it seems overkill for such a small change. But, you know, if you feel that the contract is important, it would be quite easy. And then in addition to "addAction" on MainUndoStack, we could add "addDoneAction" which takes an ImmediateCompositeUndoableAction, so there is no risk of un-done actions being not done, nor done actions being re-done.. > The way to do what you want is to make your own action and perform the > changes in the doAction method. > > ie: > Create action X > Add to main undo stack > x.doAction: > create, push and execute action A > create, push and execute action B > create, push and execute action C Sure, that would work. But to me, it's messy to have to create a subclass of action for these rather esoteric, single-trick ponies. Anyway, let me know if you want me to write a generic "ImmediateCompositeUndoableAction" class. Steve _______________________________________________ Potlatch-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/potlatch-dev
