Undo?

[bitwise]

On Tuesday, 10 October 2017 at 02:36:56 UTC, Mr. Jonse wrote:
> I requiring an undo feature in my code. Rather than go the 
> regular route of using commands, I'm wondering if D can 
> facilitate an undo system quite easily?
>
> We can think of an undo system in an app as a sort of recorder. 
> The traditional method is to use commands and inverse-commands. 
> By recording the commands one can "unwind" the program by 
> applying the inverse commands. The down side is that the app 
> must be written with this approach in mind.
>
> Storing the complete state of the app is another way which some 
> apps use but usually it is too much data to store.
>
> Since the only thing that one has to store from state of the 
> app to the next is the change in data long with creation and 
> deletion of the data, I think one could simplify the task?
>
> Is it possible to write a generic system that records the the 
> entire state changes without much boilerplate?
>
> I'm thinking that two types of attributes would work, one for 
> aggregates for creation and deletion of objects and one for 
> properties to handle the data changes. If D can be used to 
> automatically hook properties to have them report the changes 
> to the undo system and one can properly deal with object 
> creation and assignment, it might be a pretty sleek way to 
> support undo.
>
>
> Help appreciated!

I wrote an undo system for a level editor once:
https://github.com/nicolasjinchereau/pizza-quest/blob/90d1a2ae75c1f80ee13cedcfb634c6de0f9528db/source/editor/History.h

That class made it trivial to implement unlimited undo/redo.

Each object that's passed to History::AddObjectState() has to 
have `Undoable` implemented so that its state can be copied and 
replaced later if the object needs to be restored. In D though, 
you don't even really have to implement `Undoable`. You can make 
something like AddObjectState() into a template that uses D's 
`__traits`, or `tupleof` to record all of an object's fields into 
some generic undo state. I wrote that code so long ago that I 
don't really remember how I dealt with pointer ownership, but if 
you use GC allocation, or POD types, it should be easy.

With an approach like this, you don't need a discrete set of 
commands, but only objects that can be serialized before an 
operation, and restored afterward if you don't like the result.