Indexing access for Lists and Maps considered harmful?

[Ted Neward]

Under what situation would a = b = c (where b is boxed(c) ) yield different
results? Aside from concurrency scenarios, my understanding is that boxed or
not, the value is still "c", thus a would hold the value "c", boxed or
otherwise.

Note that of course concurrency/multi-threaded-access to a/b/c will change
any of this; I'm assuming a single-threaded scenario here for simplicity's
sake (and because my understanding is that this proposal is not suggesting
that the language needs to take on additional atomicity guarantees beyond
what is already defined by the JLS).

Ted Neward | Principal Consultant, ThoughtWorks
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.thoughtworks.com | http://www.tedneward.com

> -----Original Message-----
> From: Mark Thornton [mailto:mthornton at optrak.co.uk]
> Sent: Wednesday, June 24, 2009 1:03 AM
> To: Ted Neward
> Cc: coin-dev at openjdk.java.net
> Subject: Re: Indexing access for Lists and Maps considered harmful?
> 
> Ted Neward wrote:
> > preserved. Am I missing something here? If, as I think Neal already
> pointed
> > out, we look at the expression
> >
> > a = b = c;
> >
> > The results of the intermediate expression "b = c" is "c", and
> therefore the
> > results of the expression "a = (b = c)" is "c" as well. What are we
> arguing
> >
> As I understand it, if c is a primitive and b is an object then the
> result of "b=c" is boxed(c). In addition
> 
> b = boxed(c);
> a = boxed(c);
> 
> does not necessarily give the same result as
> 
> b = boxed(c);
> a = b;
> 
> Regards,
> Mark Thornton