Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: Enabling the REBOL community

From: ryanc:iesco-dms at: 9-May-2001 10:58

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 > [rebol-request--rebol--com] 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