Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.programming    |    Programming issues that transcend langua    |    57,431 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 55,659 of 57,431    |
|    Malcolm McLean to ju...@diegidio.name    |
|    Re: Undo / Redo design pattern.    |
|    04 Apr 22 01:49:03    |
      From: malcolm.arthur.mclean@gmail.com              On Monday, 4 April 2022 at 09:03:31 UTC+1, ju...@diegidio.name wrote:       > On Sunday, 3 April 2022 at 13:16:14 UTC+2, Malcolm McLean wrote:        > > To implement a simple undo redo, you need two stacks, and a copyable       representation of the program state. You then push to the undo stack, with       straight forwards extensions for redo.       > Why two stacks? I just see the need for one. And why "program state", this       is usually about a specific set of properties along some tree hierarchy so       that each property is identified by a unique path... and then, in a basic       implementation, at any        change you just record the path together with the value before change.        >       You need two stacks because after a series of undos, you have a series of       redos.       These can be in the same contiguous region of memory in a simple       implementation, but you still       have two stacks, one growing up and one growing down.       In my system, you need two actual stacks, because we only store the deltas,       except for at stack       top, where we store the entire object.        >       > That said, it's hardly the case that any diffing logic can do better than       just recording the old value in the case of "primitive" types: you can do       better for composite objects/arrays, by checking what properties have actually       changed (and extending a        little bit on the notion of changed property path). Anyway this is a further       step...        >        I don't quite follow, but I think what you are saying is that program state is       held as a graph,       then user operations are expressed as operation on that graph, and you store       the operation       in the undo system.              That is how a lot of programs work. But it means the undo/redo system       dominates the design       of the program. And it means it needs to be bespoke. Te idea is to have a       generic system, which        relies on just converting the state to and from a universal representation.       Strings are the        obvious example of a universal representation.               --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca