indexed access: 10 ways to fix 'harmfull' issue

[Ruslan Shevchenko]

10 ways, collected from discussions:


1.  Do nothing. Say, that it's a feature, not bug to have funny questions
for intervies.  x[i]=q is shortcut for x.put(i,q)
 looks strange from some point of view :  yes
 backward compability: yes
 extra  overhead:      no
 limited functionality:no

//Comment: php people just added goto to version 5.3 and start thinking
about cobol 'alter'.
 May be they know something ?

2.  Do nothing, but produce a warning when indexed assigment take part in
compound assigment
 looks strange from some point of view :  yes, but better then previous
 backward compability: yes
 extra  overhead:      no
 limited functionality: yes

//Comment: usefull operation of swapping two elements in map will cause
warning.
//2.1.  recognize this operation and does not produce warning.

3. Change semantics in assigment in that way, that indexed assigment also
return value of right part, casted
 to type of left part.
 looks strange from some point of view : minor:
// (x[i]=b)==x[i]  can be not always true, becouse we return right part
instead left.

Map<Integer,Integer> x = new HashMap<Integer,Integer>();
if ((x[1]=128)==x[1]) {
 System.err.println("eq");
} else {
 System.err.println("neq");
}
 will print neq.

int[] x = new int[1];
if ((x[1]=128)==x[1]) {
 System.err.println("eq");
} else {
 System.err.println("neq");
}
 will print eq.

 backward compability: yes (if will not change rules for arrays and
variables)
 extra  overhead:      no
 limited functionality: no

//Comment: some existing statements of JLS will be changed, but for arrays
and plain variables
// we have choise:  left the same as previous,

4. Forse result of indexed assigment be void. Therefore, it would be not
possible use indexed assigment as part
of compound assigment.
 looks strange from some point of view : yes.
 backward compability: yes
 extra  overhead:      no
 limited functionality: yes

5.  Implements only getters.
 looks strange from some point of view : yes.
 backward compability: yes
 extra  overhead:      no
 limited functionality: yes

6. Retrofit interface (with operations like getByKey and setByKey) which
return just-setted values instead previously
setted. And use setByKey() instead put.  Implement setByKey in
AbstractMap, AbstractList

 looks strange: no
 backward compability: no  (but changes are minimal: only user
implementation of Collections, which are not derived from AbstractMap or
AbstractList,
will be touched and fix [implementing setByKey()] will be trivial)
 extra  overhead:      no
 limited functionality: no

Comment: I think, that if major language version is changed, than it is
possible to introduce incompabilities.

7. Implement in Collections static method indexed_set_assigment, which
will look like:
indexed_set_assigment(Map<K,V> map, K k, V v)
{
  map.put(k,v);
  return v;
}
and let compiler will call this method during desugaring of compound
assigment.

 looks strange from some point of view : minor (same as 3).
 backward compability: yes.
 extra overhead: no
 limited functionality: no

Also introduce small interface for 'less-then-collections' indexed access.

8. Implement in Collections static method indexed_set_assigment, which
will look like:
indexed_set_assigment(Map<K,V> map, K k, V v)
{
  map.put(k,v);
  return map.get(k);
}

and then same as 7.

 looks strange from some point of view : yes, if get have side-effects,
than they will unexpected
 backward compability: yes.
 extra overhead: yes (but if call will be only during participation of
compound assigments - it will be rare)
 limited functionality: no

9. Desugar (x[i]=y) as x.put(i,y); x.get(i)
 // same as 8, but inline without extra method in library.

 looks strange from some point of view : yes, if get have side-effects,
than they will unexpected
 backward compability: yes.
 extra overhead: yes (but if call will be only during participation of
compound assigments - it will be rare)
 limited functionality: no

10. Change overriding rules, to allow override void methods by methods
with other return types. then retrofit set of
 such interfaces on list and map, than define semantics of compound
assigment as in 7

 looks strange from some point of view : yes, changes to override
semantics +minor (same as 3).
 backward compability: yes.
 extra overhead: no
 limited functionality: no

// looks like 3, but with changes to inheritance for purpose of defining
semantics of indexed assigment
// in uniform manner for collections and non-collections.

-------------
All of this (may be except 10, 9, 8) can be acceptable in some way.

Is I missed something ?