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

[Ben Wing]

Hrvoje Niksic wrote:

>Ben Wing <ben at 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.
>  
>
well, range tables do look up values using an integer.  char table 
lookup is by character, which is something like an integer (in the old 
mule way, there were gaps in the allowed integers, but this will be less 
the case with unicode).

>  
>
>>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.
>
>  
>
hmm, you're right about that.