[REBOL] UHURU unit structure
From: joel::neely::fedex::com at: 28-May-2001 10:36
More concrete, less philosophy! ;-)
I'm working on a prototype of the UHURU client-side code
today (this being a US holiday), but thought I'd pitch out
a couple of ideas, to be followed by demo code Real Soon Now
I propose that the "working code" portion of an UHURU unit
*always* have the following structure:
; header data to be discussed later
make object! [
; the usual stuff...
; *without any* SET referring to external words
and that one *always* incorporate an UHURU unit via one of
the two following means (layout/whitespace choices optional):
my-obj-name: UHURU/make unit-name
my-func-1: my-func-2: my-func-n: none ; or other null value,
; later followed by
my-func-1 my-func-2 my-func-3
] UHURU/import unit-name [
unit-func-1 unit-func-2 unit-func-n
Namespace collisions are a monumental pain in code reuse.
The simplest way to avoid any such collisions is for each
unit to be an object that *NEVER* messes with any namespace
except its own, IMHO.
Both of the above mechanisms are based on the assumption that
a unit is an object. In addition, both of these mechanisms
allow the user of a unit to "place" words based on the unit
wherever (s)he wishes in the local code under development.
I trust the first is obvious, as it is based on the idea that
a unit defines a conventional REBOL object.
The second is based the idea that a unit could represent a
of conceptually-related functions which
don't seem to be methods on a conventional REBOL object. For
example, authors might define a sets of functions for
1) hyperbolic trigonometry,
2) html generation,
3) various standard check-digit calculations (UPC/EAN,
ISBN, ABA, etc.),
4) (I'm sure you can think of others...)
There's some reasonable likelihood that each of the above
groups contains functions that may share implementation
code, may be used within the same user's local program, or
both. This means that it's A Good Thing to have them
However, there's no "thing" which holds state that methods
are working against, hence there's no benefit to forcing
the down-stream programmer either to think in terms of an
object, nor to have to repeat prefixes over and over as in:
hyp-trig: UHURU/make hyperbolic-trigonometry
a: hyp-trig/sinh x
b: hyp-trig/cosh y
c: hyp-trig/tanh z
; and so on
To accomplish IMPORT, UHURU could perform the following steps:
1) make a working copy of the unit's object,
2) verify that the supplied list of words to be IMPORTed
are actually defined within the unit's object,
3) return a block of values associated with each IMPORTed
word (as defined within the unit's object).
It's up to the user of the unit to set those values wherever
Programming languages: compact, powerful, simple ...
Pick any two!