let's play TDD, tackles closures in java

[Reinier Zwitserloot]

Excellent catch, Peter.

It feels most logical to me to define assignment as .set(). To be consistent
with e.g. foo += 5 to become a mutation on the same variable (there's not
much point creating new AtomicIntegers all over).

Nevertheless, this is never going to work right.

This snippet:

AtomicInteger foo = 10;
foo = foo + 20;

would be desugared into either:

AtomicInteger foo = new AtomicInteger(10);
foo = new AtomicInteger(foo.get() + 20);

or:

AtomicInteger foo = new AtomicInteger(10);
foo.set(foo.get() + 20);

both of which are very very wrong. Idea is beyond salvaging, as far as I'm
concerned. (and I'll use this from now on as a nice example of why operator
overloading probably does more harm than good!)

 --Reinier Zwitserloot



On Mon, Dec 20, 2010 at 12:51 PM, Peter Levart <peter.levart at marand.si>wrote:

> On 12/20/10, Reinier Zwitserloot wrote:
> > Boxing
> > for Atomics is a much bigger deal, though (as boxing for
> java.lang.Integer
> > and friends has shown). There'd be far less complexity if this boxing
> only
> > works for assignments / variable initializations.
> >
> > i.e.:
> >
> > AtomicInteger foo = 10; // this works
>
> // and would, pressumably be translated to:
> AtomicInteger foo = new AtomicInteger(10);
>
> > foo = 20; // this works
>
> // but is not known whether it should be translated to:
>  foo = new AtomicInteger(10);
> // or to:
> foo.set(10);
>
>
> Atomic* classes are mutable containers - not like immutable primitive
> wrappers that can, to some limited degree, mimic the value semantics.
>
>
> Regards, Peter
>