Indexing access for Lists and Maps considered harmful?

[Rémi Forax]

Neal Gafter a écrit :
> On Wed, Jun 24, 2009 at 8:35 AM, Rémi Forax <forax at univ-mlv.fr 
> <mailto: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.

Sorry, I think i've forget to read a mail, what is your preferred solution ?

>
>     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.

I am not confident with the fact that operator overloading depends on 
what is currently in the scope.

>
>     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.
>
This example is not artificial,
So yes I could and I guess I will not be the only one to try.

> 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.
>

That the strength of the extension methods.
But I am not sure that static import is the good way to implement 
extension methods.

static imported methods are not part of the interface of the class they 
augment
so the semantics of an index operator can be different for different 
part of a program.
I don't like that idea.

Rémi