Re: aset/aref for char-tables, range-tables etc.
Ben Wing <ben(a)xemacs.org> writes:
>Python's [] is much more than array access: it's a
syntactic shorthand
>for __getitem__/__setitem__, and it's these generic concepts that we
>lack. If we do introduce them, they should work on all kinds of
>objects (e.g. hash tables and lists), and in that case we should
>choose names better than aref/aset, because those concepts are quite
>detached from traditional meanings of "array".
>
is there any reason that aset/aref couldn't be extended semantically
to be the equivalent of python's [] (which, after all, was also
originally an "array reference" syntax)?
I suppose they could, but their implication of "array" would sound
weird to me. That's the naming issue I referred to by "choose names
better than aref/aset". While it's true that in other languages []
means array access, in Python I believe [] was used for dictionary
accesses, string accesses, and also for slices, from the start.
Using the names aref and aset sort of implies that all these things
are arrays, which they are not (except in the loose sense of
"associative array", but that term seems to be losing popularity, even
in Perl). My point is that if we introduce a new concept, we should
introduce a new name to match it. Then we can add slices,
setf-ability, and perhaps other features, from the start.
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.