newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(03-04-2018 10:09 PM)The Shadow Wrote:  I can think of refinements for both of these, though I'm not sure how practical they are to code:

a) Have LIBRCL take three arguments instead of two. The third one is a default value - if the recall fails, the default gets both returned and LIBSTO'd.

b) Instead of, or in addition to, $HANDLER, there is $DEFAULTS. This is a simple list of names and content, which are to be stored into the directory when the library is attached. There might also be a command LIBDEF which would restore the directory to the default values in case things get borked up.

I personally think that either version of b) is more elegant, provided there's a way to re-run the $HANDLER or restore the $DEFAULTS. Otherwise, programmers will effectively have to implement a) anyway.

I like a) but not as an addition to LIBRCL (BTW, LIBRCL takes a single argument, just like RCL), I think LIBDEFRCL is a more appropriate name (actually, a DEFRCL command should probably exist too as a general purpose RCL that provides a default). This way, the developer still has the option with LIBRCL of detecting the missing data (with IFERR) and doing something other than provide a default, while LIBDEFRCL will simply provide a default, which is a simple solution for 99% of cases. I don't think it should store this default, after all it will always default to this value anyway, so why waste storage.
The advantage of a) vs. b) is that a) works well when there was partial data loss or corruption. What doesn't convince me about b) (or the $HANDLER idea altogether) is that if data gets lost arbitrarily, it doesn't automatically repair it. The user would need to reinstall the library or reset it completely, losing all those settings instead of just the few that got damaged.
Also, I like that LIBCLEAR works well with LIBDEFRCL, since it will reset to default values by simply cleaning up the directory.
Regarding $DEFAULTS, I think individual values using LIBDEFRCL would work better than having a lot of default values in one large list.
Besides, you'd have to have LIBCLEAR also store the $DEFAULTS, or a different command to store the defaults. But then using LIBCLEAR would leave libraries in a non-working state, until new defaults are stored.
I don't like that "gap", so I'll go for LIBDEFRCL as the best solution.
Thanks for the idea!