Indexing access for Lists and Maps considered harmful?

[Neal Gafter]

Why would a language-support method like Puttable.put return a value that
the generated code is required to ignore?  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> 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
>
>