let's play TDD, tackles closures in java

[Artur Biesiadowski]

On 21/12/2010 08:41, Reinier Zwitserloot wrote:
>
>
> AtomicInteger foo = 10;
> foo = foo + 20;
>
> would be desugared into either:
>
> AtomicInteger foo = new AtomicInteger(10);
> foo.set(foo.get() + 20);
>

But you can write same thing with atomic integers right now ? Same way 
as you need to know difference between foo.set(foo.get() +20) versus 
foo.incrementAndGet(20), you would need to know difference between foo = 
foo+20 versus foo +=20 (and bytecodes iload, iadd, istore versus iinc)

If you are concerned about what 'normal people' would do, normal people 
will write right now

int[] holder = new int[1];
...
holder[0] += 20;

and be completely sure it is atomic and threadsafe...

But I agree that java is probably not ready for operator overloading 
yet. Same way as we constantly need to educate people that
String str = "...";
str += a;
str += b;
str += c;
is something very different from
str += a + b + c;

there would be no end to suprises about 'non-intuitive' behaviour of 
Atomic* overloads.

Regards,
Artur Biesiadowski