[REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]
From: joel:neely:fedex at: 24-May-2001 11:43
> 100% agreement up to this point. IMO <UHURU ...>..</UHURU> is not
> required - look at the REBOL header, we already have File (which is
> UHURU:unit name) and Version. By extending the header so we have,
> say, a standard like:
In my desire not to inflict a war-and-peace email on the list,
I left out some of the rationale...
The reasons I've suggested the <UHURU ...>...</UHURU> part are:
1) I assumed we'd want to keep all of the library-related stuff
*out of* the header, so as not to conflict with any plans or
future developments RT may have/make with header content.
2) I assuemd we'd want to keep "meta-data" in the UHURU XML
so that we could modify or expand it without worrying about
that increasing load times of modules being utilized. (The
meta-stuff would get stripped out by INSTALL, so that it
wouldn't be in the .r file.
3) We already have PARSE-XML, so the effort to implement the
<UHURU...> stuff should be minimal.
4) We might want to drive other tools (e.g., a keyword-search
tool) with meta-data. By putting the <UHURU ...> stuff
first, such tools could remain oblivious to all other
5) I assumed that a unit file would be maintained as a single
file by the developer. There would still be only one place
to go to perform ongoing modification on the code, docs,
> This way scripts could use their UHURU (we really need a better
> acronym I'm afraid ;)) ...
StarTrek Classic fans everywhere are priming their flamethrowers!
> ... information as metadata and the header processing the UHURU
> handling scripts would need is already built into REBOL.
Everything to parse the <UHURU...> stuff *is* already built into
REBOL (see (3) above), but the manipulation of the content would
be added code in any case. The advantage of XML over the REBOL
header block is that we get a conventional syntax for complex
data structures for free (assuming one already knows XML).
> I'd even suggest allowing UHURU-doc to be either a file, in
> which case the file is obtained, or the keyword "auto" in
> which case code like my reboldoc is used to extract the html
> documentation from the source itself (which IMO is a lot easier
> on the programmer, and thus more likely to be used properly
> - there's only one set of docs, the docs in the code, to
> maintain rather than two.)
As mentioned above, I'd like to see if we can avoid burdening the
loadable REBOL code with non-executable content, but at the same
time make it easy to supply that *with* the code. For example,
a page-long narrative on a non-trivial object, along with usage
samples, would be quite a bit of overhead to read through just
to load the object def itself, IMHO.
Anyway, those were my assumptions and preferences. I'm certainly
open to discussion leading to something we can all live with and