Indexing access for Lists and Maps considered harmful?

[Joshua Bloch]

P.S.  I typed this in a hurry.  What I meant to say is "The fact that
Map.put (and List.set) returns a value is an implementation detail (with
respect to the endeavor at hand).
         Sorry for the confusion,

         Josh

2009/6/24 Joshua Bloch <jjb at google.com>

> I'm with Artur on this.  I think we're making a mountain out of a molehill.
>  The fact that  collection.put(value) is an implementation detail.  The
> value of (a = expr) is and should remain expr.
>                    Josh
>
> 2009/6/24 <abies at adres.pl>
>
>
>>
>> "Reinier Zwitserloot" <reinier at zwitserloot.com> napisał(a):
>>  > I am beginning to see some concensus on this list that the neal
>>  > semantics are the most preferred semantics. That is:
>>  >
>>  > FOO = (a[b] = c);
>>  >
>>  > should be equal to:
>>  >
>>  > a[b] = c;
>>  > FOO = a[b];
>>  >
>>  > and thus, both a setter and a getter call.
>>
>>
>> I still don't understand why. It is not a case with current assignment
>> operator.
>> public class Test {
>> volatile static int[] arr = new int[1];
>> volatile static int val = 0;
>> public static void main(String[] args) {
>>    int x,y;
>>    x = (val = 3);
>>    y = (arr[0] = 5);
>> }
>> }
>>
>>
>> compiles into
>>
>> public static void main(java.lang.String[]);
>>  Code:
>>   0:   iconst_3
>>   1:   dup
>>   2:   putstatic       #2; //Field val:I
>>   5:   istore_1
>>   6:   getstatic       #3; //Field arr:[I
>>   9:   iconst_0
>>   10:  iconst_5
>>   11:  dup_x2
>>   12:  iastore
>>   13:  istore_2
>>   14:  return
>>
>>
>> Please note that there is no get from the arr nor from val, even if both
>> are volatile and could be possible written into by another thread
>> concurrently.
>>
>> x = (y = z)
>>
>> IS NOT EQUAL TO
>>
>> y = z;
>> x = y;
>>
>> in current java.
>>
>> It is equal to
>>
>> tmp = z;
>> y = tmp;
>> x = tmp;
>>
>> I don't understand why suddenly for sugar-on-top-of-collections we have to
>> change the rules which are valid for normal values and arrays. There is no
>> 'getter' equivalent called for anything in java currently, if you will
>> modify jvm to catch retrieve-value-from-array, it will not be invoked, so
>> why should getter be called on collections?
>>
>> Regards,
>> Artur Biesiadowski
>>
>>
>