home bbs files messages ]

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