Ben Wing <ben(a)xemacs.org> writes:
well, but how do you think the extension from [] = array to [] =
hash
tables, etc. came about? by the exact process of semantic extension.
whether is what "there at the beginning of python" is irrelevant since
python extended this notation from other languages,
That it was there at the beginning is exactly relevant to my point,
which is that Python *introduced* that notation from the start, it
didn't extend it from array access. I agree that it is extended in
the sense that the operator was borrowed from other languages where it
denoted array access. However, a syntactic shorthand is useful for
that kind of thing because it denotes a function without naming it
"array". (Python does use names for its methods, and then it's called
get/set-item.)
I believe that "aref" stands for "array reference" and that the name
is a bad one outside the array context. I don't have a really good
alternative name handy; maybe I would call it "item". In that case it
should be setfable and support CL-style keyword arguments such as
:start and :end for slices.
>>char tables are indexed by character and nothing else, but can
take
>>a charset or something similar as a shorthand for setting a value
>>for all chars in the charset. range tables are very similar but you
>>can set ranges of integers instead of charsets.
>
>Then I wouldn't really say that they are good candidates for
>aset/aref, in an "API design" sort of way. But if you feel they're
>good for compatibility, go ahead and put them in; I won't complain.
>
>
what makes them not good? the fact that they can take objects other
than integers as set arguments?
The fact that they don't look up values using an integer index, the
way an array does.
btw i semantically extended `get' from symbol properties to
general
properties, and you seemed to like it.
In that case the name `get' at least didn't imply a symbol argument.
On the other hand, `symbol-plist' does, which is why I assume
`object-plist' was introduced.