Indexing access for Lists and Maps considered harmful?

[Ruslan Shevchenko]

> Ruslan Shevchenko wrote:
>> 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.
>>
> It is very undesireable to add methods to existing interfaces. But the
> intent of this proposal was to allow indexed access to existing List/Map.
>

 i. e. without library changes ?
Hmm .... [I does not think so, but this is question to authors]


>> 2. change '=' semantics to return right part of assignment in case of
>> assignment to indexed access.
>>
> It is even more undesireable to change existing semantics. Nor is it
> desireable to have the semantics of assignment depend on whether the LHS
> is an index into a list or an index into an array.
>

 If we have different semantics of  access methods, than we have different
semantics of indexed assignments.

 JLS does not specify semantics of indexed access to list now. I. e.
statements about indexed access will be added to JLS, possible in way,
that behaviour of overall specification will look logically.

 Now we have two cases to do this:

1. Add statement, that index assignment will be translated to call of
index-assignment method (put in maps, set in lists). [In intention of
original proposal]   Note, that JLS will not become inconsistent from such
case: only semantics of returning value of put() looks strange, because
put was not designed to participate as part in compound assignment.
// that's why I think, that new method is better solution.

2. Add statement, that index assignment will be translated to call of
index-assignment method, then return value will be changed to right part
of assignment, boxed to type of left part, if needed.
  This will allow put's be part of compound assignments.

Of course, this will left other things, which looks strange:
  (a[x]=b)==b  will be not always true,
    //when b is primitive value and a[x] is collection of appropriative
boxed object types.
But note, that violation of this property also will be applied to case 1.
Semantics of access statement for arrays will not changed at all.


Is it possible to find variant, which will not looks (from some point fo
view) strange and without library changes (?) - I don't think so. If we
allow user code in compound assignments, than we allow side effects in
user code, which can change result.



> Mark Thornton
>
>