I was just thinking about this over the the weekend, almost exactly as you have
written Joel. I was amazed to read your post. The simple make object! idea is
what I came up with too. I strongly agree that such a system would especially benifit
our community.
I really would like to know RT's time frame for the release of thier module system.
--Ryan
Joel Neely 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.
--
Ryan Cole
Programmer Analyst
www.iesco-dms.com
707-468-5400
"I am enough of an artist to draw freely upon my imagination.
Imagination is more important than knowledge. Knowledge is
limited. Imagination encircles the world." -Einstein
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
