[cells-devel] More on the details...

[Mike J. Bell]

Ok, so I did a survey of the design in one of the applications I
built, and I'm pretty convinced I could move to a
completely-declarative model, with not *too* much effort.

One thing that baffles me though, is how you would go about
implementing undo/redo functionality.

In my current application, just about everything can be undone/redone,
with a theoretically infinite list of snapshots.  I had to put in some
weird mechanisms to shield the undo/redo system from saving state
*too* often, like for example if the user is dragging an object on the
screen, it only remembers where it was and where it ended up, not the
whole path.

It's unbelievably simple to implement this in our imperative
world...the undo/redo system (which, incidentally, in written in
user-land and requires no support from the architecture) listens for
changes in the specified slots, records everything when they change,
and when you tell it, will walk the stack and publish saved data at a
later time.

Obviously, when you look at most of the "core" data slots in my
application, you'll find at least three publishers:  the thing that
really calculates what it should be at runtime, and then undo, and
redo.

How do you solve this in Cells?  It sounds like it would be really
annoying to have to write "dispatch" slots that marshall the three
different possible values for every cell that falls into this
pattern...but I guess that's what macros are for.

What about integrating it into the Cells engine itself?  I mean, since
Cells is declarative, theoretically you should be able to record the
value of all the independent cells (the "roots" of your DAG of slot
dependencies) and then just reset them all accordingly to get the
whole system into the same state as it was...right?

Thanks for your comments...

-- 
Mike J. Bell on gmail