Hi List:
This is a first pass at targeting what Joel suggested. I've
created a object in "unit.r" called amazingly enough 'unit.
It's something of a crude Unit Manager, I suppose.
The 'unit has a default library path of %/c/rebol/lib but
provides the suggested function for adding new paths to the
unit manager. Then whenever you want to use an anonymous
object, you just call like so:
do %unit.r
my-new-object: unit/new %cmptest
Where you are trying to create a 'cmptest object using
%/c/rebol/lib/cmptest.r
The file extension is tacked on automatically to kind of abstract
the idea that you're just "including" a reblet somewhere. This
way you can focus on "gimme a new 'cmptest object", and not
"include %cmptest.r so I can get a new object".
If there's a another library path that your object file is in:
unit/add-lib-path %/c/rebol/powerlib
my-powerful-object: unit/new %powerline
The code for %unit.r is below.. hope this helps:
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<------------------------------------------------------------------
--John Schuhr
At 07:36 PM 5/8/2001 -0500, you wrote:
>Those who are familiar with CPAN (the Comprehensive Perl
>Archive Network) know that it is a significant factor in
>the growth -- and ease of use -- of Perl. CPAN modules
>provide:
>
>1) A community-maintained, standard namespace for modules,
> (e.g., a reasonable tree-structured taxonomy which
> helps the programmer remember "where" a module is).
>2) A collection of mirror sites from which modules may be
> obtained.
>3) A simple set of mechanisms for acquiring a module and
> installing it in the standard place on one's local box.
>4) A means of ensuring that a module has been successfully
> loaded into a running program that wishes to use it.
>5) A means of controlling the effect that loading the
> module has on the global namespace.
>6) A rich source of examples for newcomers learning the
> language, as well as for older hands wanting to polish
> their style.
>
>I've seen many useful pieces of REBOL code written and
>shared during the time I've been subscribed to this list.
>I've written one or two tidbits that I hope someone has
>found useful. But... where is all of this good stuff???
>
>Some of it is in the mailing list archives, some of it
>is on various individual or group sites, some may be
>lost. This is sad, since there are many good wheels out
>there that don't need to be re-invented.
>
>Several of us (myself included) have written our own tools
>for "include"-ing a REBOL module from a local library into a
>running script. However, it occurs to me that this kind of
>infrastructure itself is a wheel that doesn't need to be
>re-invented.
>
>All of this musing motivates a couple of specific questions:
>
>1) Can we -- as a community -- begin to build the same kind
> of resource for REBOL that CPAN serves for Perl?
>2) Can we agree on (or at least discuss) the kinds of
> standards/conventions/features that would make such a
> resource effective for the old hands and easy for the
> new kids on the block?
>
>Let me give an example of the kind of thing I mean in the
>second point. I've been toying with the idea that a re-
>usable code unit could take the form of an "anonymous"
>object, something like the following:
>
>8<------------------------------------------------------------
>rebol [
> title: "Component test"
> file: "cmptest.r"
> author: "Joel Neely"
> version: 0.1.0
> date: 08-May-2001
> history: [
> 0.1.0 [
> 08-May-2001 {Preliminary proposal draft}
> ]
> ]
>]
>
>make object! [
> x: 1
> y: 42
> sum: does [x + y]
>]
>8<------------------------------------------------------------
>
>At some level down under the hood, this could be included into
>another script by the equivalent of...
>
>8<------------------------------------------------------------
> >> testobject: do %cmptest.r
> >> testobject/sum
>== 43
>8<------------------------------------------------------------
>
>but also by embedding inside other objects, as in...
>
>8<------------------------------------------------------------
> >> foo: make object! [
>[ red: 23
>[ yellow: 48
>[ caramel: do %cmptest.r
>[ ]
> >> source foo
>foo:
>make object! [
> red: 23
> yellow: 48
> caramel:
> make object! [
> x: 1
> y: 42
> sum: func [][x + y]
> ]
>]
> >> foo/caramel/sum
>== 43
>8<------------------------------------------------------------
>
>The point of the anonymity is, of course, to avoid the danger
>of conflicting with other words defined by the code that uses
>the unit (or with words defined by other units).
>
>The point of the phrase "at some level under the hood" above
>is that I don't think a simple "do %unitname.r" is the right
>solution. I suggest that the unit/module/component management
>mechanism contain the idea of a standard path (or set of paths)
>so that units stored in the canonical place are accessible to
>any using code regardless of where in the directory structure
>it (either one!) appears.
>
>Therefore, the actual usage might resemble something like
>
>8<------------------------------------------------------------
>unit/add-unit-path %lib/ideas
>
> >> foo: make object! [
>[ red: 23
>[ yellow: 48
>[ caramel: unit/do %cmptest.r
>[ ]
>...
>8<------------------------------------------------------------
>
>which might imply that the file cmptest.r is in the lib/ideas
>subdirectory under whatever is the standard library path (or
>one of the standard library paths!) on the current box. Thus
>the code above wouldn't change if I move to a different box or
>platform with different library placement conventions (this,
>of course, assumes that */lib/ideas/cmptest.r is in the "right"
>library path for the other box/platform).
>
>Comments, suggestions, alternatives, collaborators???
>
>-jn-
>--
>To unsubscribe from this list, please send an email to
>[EMAIL PROTECTED] with "unsubscribe" in the
>subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
