Posit: Unlimited "Undo" in fP?

[bruce at stn.com]

Quoting Fairlight <fairlite at fairlite.com>:
> 
> Well, I was thinking about this from my article when I wrote it late
> last
> week.  I had a section on software having Undo features.
> 
> Got me thinking about fP...
> 
> What happens if you take a table on which you're altering data, and
> @wef*
> or any other appropriate events, you actually take a "snapshot" of the
> record into a secondary backup table, complete with an added session
> and
> sequence number?
> 
> In this fashion, you could assign some way of triggering an Undo, which
> would take data from the last sequence number on the stack for that
> session.  After the session (however you define it...say you have a
> step
> that finalises a transaction), you could just delete all "step" records
> in
> the backup file for that session number.
> 
> Technically, you could implement Redo as well by keeping a counter of
> which
> step you're on and just pulling the sequence number forward instead of
> backwards, and not deleting -any- records until things are finalised.
> 
> I thought this might be an interesting thing to toss around as an idea
> for
> implementation.  Could be handy in some environments/instances.
> 
> Technically, it could be expanded to header/detail as well, obviously
> at
> the cost of some (more!) processing.
> 
> Actually, I was thinking it might be painful to have to code new
> Undo/Redo
> for each table, but it might be possible to make is modular, as long as
> you had 997 fields or less in actual use so you have two available.

How about having a single undo-value file that is keyed on:

1. session
2. fld#

and where your undo-values are fields 3+ on that one record?


> It's
> possible to do with special formatting and use only 1 field, I suppose.
> But basically just make a copy of any file you want to have Undo/Redo,
> and the only thing that needs to change is the lookup name.  The rest
> of
> the code could be handled generically with an array laid over the
> lookup
> alias, so you just store fields 1-997, period, file agnostically. 
> Minimal
> processing rewrite.  I can't think of a way to make it a "true" module
> since you can't variablise lookup file names (to my knowledge).  

Yes - you can do that.  Just don't install a creation password on 
the file that the lookup expression evaluates to if you plan to 
sell anyone runtimes since they'll get prompted for the creation 
password at runtime.

> If you
> could, I think it'd be possible if you could always guaranetee the same
> index for the one field.  And I -know- you can't use a variable for the
> index--I've asked.

Yeah, it's a pain not being able to use a variable for an index, although 
you can do something like (don't have fp open so I'll call this fPseudo code):

on (asc(doedit(allup,idxltr))-"64") goto doidxa,doidxb,doidxc . . .

> 
[..]

Bruce

Bruce Easton
STN, Inc.