Re: aset/aref for char-tables, range-tables etc.

Ben Wing <ben(a)666.com&gt; 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".