Indexing access for Lists and Maps considered harmful?

[Ruslan Shevchenko]

> because they don't obey to the late binding mechanism.
> Furthermore, I don't think kthey are needed here, a simple keyword is
> sufficient.
> Let's call it "indexer"
>
> public interface List<E> {
>    indexer public E get(int index);
> }
>

> public class MyIntList {
>   indexer public void set(int index, int value) { ... }
> }
>
> There is just a small problem, coin doesn't allow new keyword ...
>


Special annotation can be used.  (as in Simple Operator Overloading proposal)

i.e.
public class MyIntList {
   @Indexer
   public void set(int index, int value) { ... }
}



But I steel can't understand: why this is better then:

1. retrofit interface with names (and semantics), other then put/get
indexedGetter/ingexedSetter

(I prefer names  #"operator:[]" and #"operator:[]=" )

and semantics for #"operator:[]=" must be return just assigned value,
not previous.

2. change '=' semantics to return right part of assignment in case of
assignment to indexed access.

 any from this solutions fix issue with compound assignment nicely.



> We will need extension methods if we want closures, but
> we will see later.
>
>>
>>
>>> NB: I'd hereby like to repeat my suggestion to choose pragmatism over
>>> perfection here:
>>>
>>
>>
>> Sure, if there were a conflict between the two (there isn't) that would
>> be
>> reasonable.  Adding direct support for the collection interfaces to the
>> JLS
>> isn't a reasonable approach either.
>>
>> Cheers,
>> Neal
>>
>>
> Cheers,
> RИmi
>
>