[EMAIL PROTECTED] wrote:
>
> It would be really really nice if RT could give us something like this (hint
> hint):
>
> assoc: make associative! []
> assoc/key: "value"
>
> 'first could give us the keys
> and 'second could give us the values
>
Please, no!
First, let me quickly point out my own culpability in submitting a QAD
that used only string! values as keys, but I would NOT like to have a
built-in associative store that only used string! (as in my sketch) or
word! (as implied by the above) values as keys. Any data type
supported by the language should be acceptable as a key. REBOL
shouldn't have any second-class citizens.
Second, as long as REBOL is dependent on the set-*! types, the above
notation has a serious problem. Suppose I had
this-key: ;some complicated expression evaluating to a key
this-val: ;some other complicated expression for a value
I would then be unable to say
assoc/:this-key: this-val
Whatever notation might be in a future version of REBOL for associative
data stores, it should NOT penalize the use of variables.
Third, IMHO it would be VERY bad to force implementation details (such
as how or where keys and values are stored) upon the user of the CONCEPT
of associative array. The words 'first, 'second, etc. describe
position,
which is fine if I'm working on a data structure where the order of the
elements is the most relevant thing to know. I believe them to be
entirely inappropriate when used in a context such as
"I want the key values to this associative store. I happen to
know that the keys are the first component of its representation
(at least in REBOL 7.9) so I'll get them using 'first."
Suppose (this is hypthetical, but please look beyond the specifics
of the example to the underlying principle) Carl and company figure
out a new memory management technique in the course of fixing the
"use vs. GC" bug (hint, hint ;-) and decide to change the internal
representation of objects so that the list of words within the object's
context is no longer the "first" attribute of the object. How many
scripts would break if they made that change? OTOH, suppose we had
an interface to objects and functions that would allow one to say
fun-context: get-context some-function
obj-context: get-context some-object
bind-to-context fun-context word-list
bind-to-context fun-context word-list
etc. In other words, real support for context! as a first-class
data type, along with meaningful names for officially sanctioned
interfaces to, and operations using, context! values.
Wouldn't that be clearer to read, easier to learn, and give RT more
opportunities for optimizing/upgrading/tweaking implementations without
any concern that doing so would invalidate existing tricky code?
-jn-
