Indexing access for Lists and Maps considered harmful?

[Joseph D. Darcy]

Neal Gafter wrote:
> Why would a language-support method like Puttable.put return a value 
> that the generated code is required to ignore?  

I am not proposing that the value is required to be ignored.  My current 
thinking is that compiler warnings are sufficient to deal with the 
multiple assignment situation in indexed access.  Aggregates outside 
java.util.Collection could choose to be Puttable<KeyType, Void.class> to 
avoid having to return some value.

-Joe

> From the point of view of designing a language-support API, it makes 
> no sense whatsoever.  The return type is vestigal: it is only present 
> because of the way that we are considering retrofitting it onto some 
> existing APIs, but it forces any new APIs that are retrofitted to 
> return some (arbitrary) value to be ignored.  It also imposes a 
> performance penalty on implementations that can more efficiently 
> overwrite a mapping than overwrite AND return the old value.  This is 
> a language-design smell that suggests we should consider finding 
> another strategy for getting the effect of index operators.
>
> On Tue, Jun 23, 2009 at 10:36 AM, Joseph D. Darcy <Joe.Darcy at sun.com 
> <mailto:Joe.Darcy at sun.com>> wrote:
>
>     spamolovko wrote:
>
>     [snip]
>     >
>     > PS i remember that coin project had discussion about usage of
>     special
>     > interface for "indexing access". That interface have to use it's own
>     > methods for access to data, so no problems with get semantic.
>     >
>     > Example:
>     >
>     > public interface Indexer<KeyType, ValueType> {
>     >
>     >     public ValueType indexGet(KeyType key);
>     >
>     >     public void indexSet(KeyType key, ValueType value);
>     >
>     > }
>     >
>
>     [snip]
>
>     The idea would be to retrofit new superinterfaces onto the List
>     and Map
>     interfaces without adding new methods to the interfaces. For example,
>     here is a slight refinement of strawman interfaces of that sort
>     from my
>     JavaOne talk:
>
>     // New superinterfaces to indicate syntax?
>     interface GettableFromInt<E> {
>     E get(int);
>     }
>
>     interface Gettable<K, V> {
>     V get(K k);
>     }
>
>     interface Settable<E> {
>     E set(int, E e);
>     }
>     interface Puttable<K, V> {
>     V put(K k, V v);
>     }
>
>     java.util.List<E> extends GettableFromInt<E>, Settable<E>, …
>
>     java.util.Map<K, V> extends Gettable<Object, V>, Puttable(K, V), …
>
>     The names "Gettable" etc. are open to improvement :-)
>
>     -Joe
>
>