Hi, John, (and everybody else)
Just a couple of suggestions...
John Schuhr wrote:
>
> Hi List:
>
> This is a first pass at targeting what Joel suggested...
>
> 8<------------------------------------------------------------------
> REBOL [
> Title: "Rebol Unit Manager"
> File: "unit.r"
> Author: "John Schuhr"
> Version: 0.1.0
> Date: 8-Aug-2001
> ]
>
> unit: make object! [
> lib-paths: [%/c/rebol/lib]
> add-lib-path: func [new-path [file!]] [
> append lib-paths new-path
> ]
> new: func [requested-unit [file!] /local new-unit valid-unit] [
> valid-unit: make logic! false
> foreach lib-path lib-paths [
> requested-unit-location: join lib-path join "/"
> join requested-unit ".r"
> if exists? requested-unit-location [
> new-unit: do requested-unit-location
> valid-unit: true
> break
> ]
> ]
> if equal? valid-unit false [
> make error! "Invalid unit specified"
> ]
> new-unit
> ]
> ]
>
> protect [unit]
>
> 8<------------------------------------------------------------------
Good start! Note that the JOIN convention also allows one to write
such things as
cdf-parser: unit/new %textproc/parsers/cdf
I suggest that unit.r (or whatever we come up with) be invoked from
within user.r (or maybe rebol.r????) so that it is just always
there,
even when running interactively.
The NEW function can tightened up a tad, as follows:
new: func [requested-unit [file!] /local new-unit] [
foreach lib-path lib-paths [
if exists? requested-unit-location:
join lib-path ["/" requested-unit ".r"]
[
return do requested-unit-location
]
]
make error! "Unknown unit specified"
]
The point of the rewording to "Unknown unit specified" is to allow
for the possibility of changing the body of the loop to
if exists? requested-unit-location:
join lib-path join "/" join requested-unit ".r"
[
if error? try [
return do requested-unit-location
][
return make error!
join "Error doing unit '" [
to-string requested-unit "'"
]
]
]
if one really wants distinct and meaningful error messages.
Another suggestion, for cross-platform portability, is to start
with an empty lib-paths block. If unit.r itself is DOne in
the user.r file, then user.r could actually contain something like
do %/usr/local/bin/rebol-lib/unit.r
unit/add-lib-path %/usr/local/bin/rebol-lib
unit/add-lib-path %/home/myacct/rebol-dev/lib
on one box, and
do %/c/rebol/unit.r
unit/add-lib-path %/c/rebol/lib
on another. That way the code within unit.r doesn't have to be
touched if I install it on a new platform.
All that said, the larger meta-question remains, "Is this -- or
something close -- a sufficient mechanism that we could begin to
use it as a de facto standard within the community?"
If so, can we begin to think about some of the other points,
such as a conventional tree structure for the units to live in,
and (harder) do we need a way to keep units from messing with
the global namespace?
-jn-
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
