let's play TDD, tackles closures in java

[Reinier Zwitserloot]

One of the coin proposals I'm going to write up if I have the time (I have
no idea when coin:flip will be) is to add support for all the operators to
BigDecimal, BigInteger, and Atomic*. I have yet to hear of an argument for
why this hasn't been done yet, other than 'makes the language more
complicated' which seems to be a case of the tail wagging the dog. 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
foo = 20; // this works

public void method(AtomicInteger i) {}

method(10); // this doesn't.


... but that wouldn't be consistent with the current auto-boxing rules.
Still, I doubt its a good idea to add even more complexity to method
resolution. If I have 3 methods all named 'foo', one takes a short, the
other takes a Long, and the third takes an AtomicInteger, and I call
foo(20), which one is called?

 --Reinier Zwitserloot



On Sat, Dec 18, 2010 at 11:17 PM, Artur Biesiadowski <abies at adres.pl> wrote:

> On 16/12/2010 08:30, Florian Weimer wrote:
> >
> > We can turn this into:
> >
> > final BooleanReference fired = new BooleanReference(false);
> > model.addTableModelListener(#{e ->  fired.setValue(true)});
> > model.doThing();
> > assertTrue(fired.getValue());
>
> You can as well use AtomicBoolean, which has an extra benefit of having
> defined behaviour in multithreaded case.
>
> I suppose that 95% of the cases of 'ugliness' people are rising could be
> solve by adding kind of autoboxing for Atomic* classes.
>
> AtomicBoolean fired = false;
>
> model.addTableModelListener(#{e ->  fired = true;});
>
> model.doThing();
>
> assertTrue(fired.get()); // or assertTrue((boolean)fired); or even
> assertTrue(fired) as assertTrue is expecting boolean only, not object ref
>
>
> With mapping of AtomicInteger.addAndGet to +=, ++,-- to
> increment/decrementAndGet, you will even get multithreaded sum thing
> working out of the box.
>
> While I'm not big fan of another set of magic dependencies (after String
> contatenation and java.lang.Integer/etc autoboxing), I still find it a
> lot cleaner that most of the solutions for transparent shared variable
> access.
>
> Regards,
> Artur Biesiadowski
>
>