[REBOL] Re: serious proposition...WAS: RE: Standards
From: antonr:iinet:au at: 10-Nov-2003 18:04
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?
(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
Imagine a script uses two functions; f1 & f2, and they both need
- f1 and f2 each try to load f3 into its context when they are loaded,
- 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:
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
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.