[REBOL] Re: UHURU/RSL/? summary
From: gjones05:mail:orion at: 25-May-2001 16:29
From: "Chris"
<snip>
> 1_4_2_93_2Pre3B1 or something equally ridiculous, ...
Darn! :-)
> A side effect of the latter is that dependancy checks can obtain the
correct
> version without the need for two dependancy blocks:
>
> depends-on [/text/conversion/delimited-ascii-2
/foo/bar/thingy-1]
> as opposed to
>
> depends-on [/text/conversion/delimited-ascii /foo/bar/thingy]
> depends-versions [2 1]
Tcl, by way of example, seems to use both. A subcategory of a library
might be tcllib. Folders holding separate versions are named
differently, like:
lib
...
tcllib0.6.1
tcllib0.8
...
However within each of these versions the subfolders are named
identically and without version. The actual package name is typically a
single name without version, but then the version of the package is
embedded in the code as such:
for C:\Program Files\TclPro1.4\lib\tcllib0.6.1\base64\base64.tcl
contains a line of code like:
package provide base64 2.0
whereas, C:\Program Files\TclPro1.4\lib\tcllib0.8\base64\base64.tcl
contains a line of code like:
package provide base64 2.1
I highly suspect that there was an excellent rationale given (does
anyone happen to know?), but I guess the system could have evolved. I
do know that the interpreter can easily query and interact with the
version numbers. In Tcl, because there is no standard header, an
explicit line of code would guarantee that code could interact with the
version information. However, I guess that since the proposed standard
RSL header would contain the filename, and that filename would then have
the version number embedded, that further explicit versioning
commands/data would add redundant storage, which is a Bad Thing, in my
opinion (more opportunity for errors).
Therefore, my intuitive guess is that the former method (eg .../thingy-1
type) is probably the more robust method. Dissention is welcome, of
course.
I've decided, Chris, that you could make a Magna Carta out of conffetti.
Great job.
--Scott Jones