Software Development

2. Have commands be able to undo what they did on their own. This way, I can store the command itself in the stack and simply ask each command to undo itself whenever necessary.

Advantages: Easy to implement the stack and uses very little memory.
Disadvantages: If a command doesn't implement undo correctly, everything is FUBAR. It's also tedious to ask developers to implement their own undo every time. Some operations can be complex and wide reaching.

3. Create a diff between the old and new state and store that. With the diff, you can reverse the operations by applying the diff in reverse order.

Advantages: Doesn't use much memory.
Disadvantages: Is difficult to automatically track all the changes unless you temporarilly save the old state before any command. Tracking the changes themselves can also be tedious and error-prone.

Are there other ways of implementing undo?

I can think of one. Instead of working backwards, you work forward. So you save two copies of the state. The first state is called the original state, and the second state is called the final state. Also, let's assume that we want to store a maximum of 10 undo operations.

Each time we do an action, we update the final state and store the command into the undo QUEUE! If there are more than 10 commands in the undo queue, then we execute the first command in the queue on the original state. Then we delete that command from the queue.

What this does is that any time we want to undo, we simply execute all the commands in the undo queue onto a duplicate of the original state. But we make sure NOT to execute the last command. If we undo twice, we don't execute the last two commands, etc. This enables us to have a history of commands. We can even jump around.

The drawback here is that you need to store two states. I wish there was a way to cut down the size of the original state. Not sure how to do that.


I really want a way to have undo's be automatic. No way I'm gonna implement commands that have to undo themselves.

In case anyone cares about my main data structures, I have three.

1. Node (contains Name, ID, Value, forward sets and reverse sets)
2. Forward sets (contains nodes).
3. Reverse sets (contains nodes).

Oh, and sets are named too, but that shouldn't matter much. A reverse set is to know what points to the current node. For example, the "Base" set is a reverse set because it points backwards. The "Derived" sets points forward to derived nodes.

Think of reverse sets as backlinks. They are automatic.

Consider node A, B, C and X. X has all of A, B and C for base types. So A will have X in its Derived set. B will have X in its Derived Set. C will have X in its Derived Set. OTOH, X will have A, B and C in its reverse Base set. Usually, forward sets and reverse sets have identical names. But this is not a requirement. IOW, it defaults to the same name, but you can override it.

Now that I have events implemented, I can track any and all changes to the network. Still, it seems somewhat overwhelming of a task. I'll have to think about it for a while.

Oh, one last thing. A lot of commands have temporary changes. Meaning that these changes should not be tracked at all.