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

[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-