Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: serious proposition...WAS: RE: Standards

From: antonr:iinet:au at: 10-Nov-2003 18:04

Mmmmm.. ok. Scenario 1 Imagine a function "f1" in a library of functions. It needs to have a function "f2" defined from another library to work properly, but an older version of f2 doesn't work, and f1 knows about that incompatibility. How should it be specified that the old version is no good and what action should be taken when f1 is attempted to be loaded? Possible actions: (A) f2 just tries to use whatever version of f1 is currently installed. (B) f2 downloads the latest f1 (into the cache) and uses it. (C) f2 downloads the latest f1 and uses it (without overwriting the cache). (D) f2 advises the user with an message dialog about the clash and asks which action to take. Problems of the above actions: (A) the f2 program will probably fail, because the old version of f1 is known to be incompatible. (B) f2 will work fine, but now there is a new version of f1, other programs that used to work fine may now not work. (C) f2 and other programs will work fine as long as there is a net connection and the user doesn't mind f2 using it. (D) User may interpret that as unfriendly, not smart enough to handle the case without supervision. I think the solution is to have a versioning notation system that separates "new-feature" versions and "bug-fix" versions. But you have to be strict in doing that. (Quite often in adding new features to a library I catch some errors while I'm there. Really, using such a system I should make two separate releases.) The user should be notified with full information (as possible) about the "upgrade" options and what they do (bug-fix/new-feature). Of course, this requires more discipline and takes more effort to maintain. ---- Scenario 2 Imagine a script uses two functions; f1 & f2, and they both need function f3. Should: - f1 and f2 each try to load f3 into its context when they are loaded, or .. - the main script load f3 into its context once (so that it is available to f1 and f2) ? In the first case, it's possible that two different copies of f3 exist and strange results may be experienced if it has "static" variables. This seems memory inefficient, though the situation can be caught, and a reference to the first instance of f3 loaded can be returned to subsequent user-programs that ask for f3. ie. f1 tries to load f3 and gets it ok. Now f2 tries to load f3 and gets a reference to the first instance of f3 that f1 has already loaded, so now: f1 f2 \ / \/ f3 That "caching" ability of the include function isn't so hard (I haven't written it yet for mine), but how, now, do you specify that you *do* want to load a new instance (say, if f1 wants to modify f3's code a bit, but f2 doesn't), or you *do* want to overwrite the first instance of f3 (say, you just downloaded a new version and you want to dynamically refresh). Ok, these options can be handled with refinements, but grr...! complication! Which options should be the less-harmful, defaults ? It probably depends what kind of data you are loading. Better make a neat system and document really clearly. In the second case, the main contexts' words have been polluted by f3, a support function only needed by f1 and f2 ! ("I didn't *ask* for "f3", I only asked for "f1" and "f2". If I wanted f3 I would have asked for it!!!!) --- These issues plague my mind so much when I think about it I have to switch off for a while in order to get anything done. :) My other idea, which I will continue to pursue at some point, is to make a dedicated downloader for any site. It can tell you which scripts are out-of-date, download all, or a selection, for you automatically, show information about newer/older versions, and also be able to revert selected scripts to older versions. Anton.