[REBOL] Associative Data Store Re:(5)
From: joel:neely:fedex at: 19-Sep-2000 8:35
Hi, Andrew!
[Al--Bri--xtra--co--nz] wrote:
> > It would be very pleasant, IMHO, to be able to write something like the
> following sketch:
> > age-grade-tab/put a-g 1 + any [age-grade-tab/get a-g 0]
>
> Will this do?
>
> Associate age-grade-tab a-g 1 + any [associate? age-grade-tab a-g 0]
>
> > foreach k age-grade-tab/keys [
> > print [k ":" age-grade-tab/get k]
> > ]
>
> How about this?
>
> use [Keys] [
> Keys: age-grade-tab
> forskip 'Keys 2 [
> print [first Keys ":" Associate? Keys]
> ]
> ]
>
> > foreach k sort/compare age-grade-tab/keys age-grade-sorter [
> > ; with some nice layout tricks not relevant to this point
> > ]
>
> foreach [Key Value] sort/compare/skip age-grade-tab age-grade-sorter 2 [
>
Of course! Thank you!
1) The motivation for my original note on the age/grade example was
specifically to explain why I believe there are reasonable uses
for block! data as keys. If memory serves, your Associate and
Associate? functions support that capability. So I think we're in
violent agreement here ;-) since we're dealing with the same
concept.
2) The main difference between our proposals is whether to use a
collection of functions or an object-oriented approach. That
discussion gets us into deeper waters. I tend to use objects
wherever possible for a bunch of reasons:
2.1) I like to keep as much as possible out of the global namespace.
This reduces my risk of name collision when reusing code.
2.2) I like having the data structure definition in the same
physical source file (always!) as the algorithms that work
with/on it. This reduces my risk of inadvertent changes or incon-
sistency when applying functions to independently-built data
structures.
2.3) I like being able to define the required behavior of an
object, and (once I've implemented it) think of the object
ONLY in terms of the interface to invoke those behaviors. This
reduces my risk of breaking code that uses the object if I later
figure out a better implementation and change the "insides" of
the function.
I'll stop with those three, but hope that I've laid the basis for
the real issue -- I think it makes sense to look at programming
from a cost/benefit analysis perspective. The reduction of risk
issues I raised above are benefits (to me, at least -- YMMV)
The cost of using objects (in ANY language) typically includes a
bit of overhead due to additional indirection in accessing the
components of the object. The cost of using objects in REBOL (at
least at THIS point in time) incudes the fact that everything in
an object is cloned when it is used as a template for creating
another object.
For most of my purposes, those costs are not high enough to
outweigh the benefits; I certainly have no quarrel with anyone
whose evaluation of the tradeoff differs. (It does sadden me
when these differences are either ignored or used as the basis
of holy wars, however.)
The bottom line is that I'd prefer a language that gives me as
general and wide-ranging set of concepts as possible, and leaves
the tradeoff decisions to me (on a case-by-case basis, even).
I think that's much better, in general, than having such choices
made in advance by the language (concept, notation, or implemen-
tation) and set in concrete.
-jn-