let's play TDD, tackles closures in java

[Llewellyn Falco]

>
> > boolean fired = false;
> > model.addTableModelListener(#{e -> fired = true});
> > model.doThing();
> > assertTrue(fired);
>
> So, in what thread is the closure going to get executed?  Listeners are
> generally fired in the EDT (in correctly written programs).  Which means
> that this code example has a data race, and is therefore broken.
>
> This is *exactly* why the stricture against mutating locals from closures
> is in place!
>
>
let's start here: the model.doThing() is obviously what is triggering the
event, so it's a single threaded test, and the current thread is what is
triggering the event. So not broken.

>Who is making these "industry standard recommendations"?  I don't know
anyone who thinks the "one-
> element-array" hack is a good idea.  If this is what people are
recommending to you, perhaps you should take
> your recommendations from someone else....

 James Shore is one of the top agilist in the world. This was made shortly
after returning from speaking in OreDev. This is not to say I agree with him
on everything, but it is does show that this is a REAL issue.
again, as a language is written, the goal should be the "pit of success".
That is, the language should help to you to stumble into "good" code. This
is exactly what interfaces did with java. Took something that completely
existed in c++ (totally abstract classes) and promoted them so every
developer started using them, and using them (more) correctly.

You might argue that people "shouldn't" write the above code.
I am trying to be a messenger, to let you know that people are "going" to be
writing this code,
Books will be written teaching this code.
Blogs will be show off the "correct" way to access local variables.

this is the path you are heading on....

llewellyn