Re: aset/aref for char-tables, range-tables etc.
Hrvoje Niksic wrote:
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)?
>
>
btw Hrvoje could you *PLEASE* *PLEASE* not remove my name from the Cc:
list? afaik it is now considered very bad netiquette to do that;
removing duplicate mails on your end is trivial using procmail. you
should not be kludging around a bug and messing up people like me in the
process.
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.
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, i.e. the notation
itself evolved semantically over time. what do we gain by creating yet
another accessor name rather than just using the already-known name?
and what would you call it?
btw i would not use aset/aref for linked lists *precisely* for the
reason that python probably wouldn't -- because underlyingly, they do
suggest some sort of array-type lookup, which implies a constant or
almost-constant access time. this applies to hash-tables, char-tables,
range-tables, etc. but most definitely not to linked lists.
>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?
btw i semantically extended `get' from symbol properties to general
properties, and you seemed to like it.
ben