Indexing access for Lists and Maps considered harmful?
Jean Louis Ardoint
ARDOINT at fr.ibm.com
Tue Jun 23 05:09:27 PDT 2009
You can also easily encounter this with prefix or postfix operators and
autoboxing, like in:
Map<Integer,Integer> m;
...
m[i] = m[i++]++ = i++;
Jean-Louis
From:
Bruce Chapman <brucechapman at paradise.net.nz>
To:
coin-dev <coin-dev at openjdk.java.net>
Date:
23/06/2009 12:04
Subject:
Re: Indexing access for Lists and Maps considered harmful?
Sent by:
coin-dev-bounces at openjdk.java.net
Talden wrote:
>> ... We can have that if the construct is defined by
>> translation as:
>>
>> var tmp = "c";
>> map.put("b", tmp);
>> tmp
>>
>
> This is my preference too...
>
> m[a] = n[a] = x; // where m and n are maps.
>
> becomes
>
> X t = x;
> m.put(a, t); n.put(a, t);
> t;
>
Not quite! because assignment is right associative - therfore
m[a] = n[a] = x;
happens in the same order as
m[a] = (n[a] = x);
and therefore your translation should be
becomes
X t = x;
n.put(a, t);
m.put(a, t);
t;
The difference could be detected for example when n and m were both
references to the same LinkedHashMap and the keys were different therefore
the order of iteration would reflect the order of assignment.
Bruce
> Does semantically treating all multi-assignments this way break existing
code?
>
> a = b = c;
>
> C t = c;
> a = t; b = t;
> t;
>
> Are there ways to get other side-effects in the current grammar? If
> not, defining it this way makes defining it for indexed access easier.
>
> PS: I've thought about this just long enough to write this email, it's
> one of those days... I must have missed something that makes this a
> more complex discussion other than 'this is how we should define the
> value of an indexed access expression'.
>
> --
> Talden
>
>
Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 02430
More information about the coin-dev
mailing list