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

[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: REBOL [ ; 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 or my-func-1: my-func-2: my-func-n: none ; or other null value, ; later followed by set [ my-func-1 my-func-2 my-func-3 ] UHURU/import unit-name [ unit-func-1 unit-func-2 unit-func-n ] Why???? 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 function library 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 packaged together. 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 (s)he wishes. -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com