Indexing access for Lists and Maps considered harmful?

[Neal Gafter]

On Wed, Jun 24, 2009 at 8:35 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

> import static put symbol name is the scope, do you propose that the
> compiler look for
> any "operator_index_get" in the scope ?


As I said, this is not my preferred solution to this problem space, but if
you take this approach, then yes.

 import static java.util.Collections.operator_index_get;
>
> class A {
>  List<String> list;
>
>  public int operator_index_get(Object o, int index) {
>     ...
>     return list[index];
>  }
> }
>
> How this example is translated by the compiler ?


The same way it translates any self-recursive method.  Do you think it
likely that someone would accidentally write a method like that?  FindBugs
will point out this problem.  This is one of the reasons I prefer an
approach based on extension methods.

Morever with extension methods is that you loose the polymorphism :


I think you mean that the spec depends on ad-hoc polymorphism (overloading)
rather than subtype polymorphism (overriding).  The actual implementation of
the operators, as I've shown, do indeed depend on subtype polymorphism in
precisely the same way as the original proposal.  The original proposal
simply cannot be retrofitted onto the interface Collection at all, and
you've shown that this proposal could (though your choice of implementation
is problematic).  Just because you could doesn't mean you should.

Looking at it another way: this alternative encodes the meaning of the index
operators in external APIs, instead of hardcoding them in the (external)
JLS.  APIs can be overloaded, and can be defined in terms of methods that
may be overridden.  The JLS cannot be "overloaded" or "overridden" at all.