Ben Wing <ben(a)666.com> writes:
i originally decided that it was a bad idea to allow aset/aref to
operate over char-tables and range-tables, like FSF does. but now
i'm not so sure. for one, i recently added a change to use
char-tables in place of 256-element vectors for the return value of
`make-display-table', and code in w3 and x-symbol (and probably
elsewhere) broke.
I think aset/aref make for array-like objects, that is, random-access
data structures indexed by integers. If char-tables and range-tables
use special character properties, other than its code, to "find" the
value, they are IMHO not good candidates for aset/aref.
make-display-table is a question of backward and possibly of
cross-Emacs compatibility. There might be good ways to handle that,
but they seem orthogonal to your primary question.
but more to the point, i'm influenced by python, which uses []
for
accessing arrays and hash tables ("dictionaries"), including ranges
in arrays (the slice notation); and both char-tables and
range-tables are basically just sparse arrays, with some
optimizations.
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".