let's play TDD, tackles closures in java

[Alessio Stalla]

On Mon, Dec 20, 2010 at 4:42 PM, Llewellyn Falco <isidore at setgame.com> wrote:
[snip]
> 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....

I don't agree. Mind you, I'm on the side of capturing all lexical
variables too, not just (effectively) final ones, but yours is not the
reason for wanting it. I have used the array hack myself in the past,
in multithreaded code (with - hopefully - the appropriate
synchronization), but if I had had atomic references, I would have
used them. And anyway all of this stuff is independent from lambdas,
we have the same issues with inner classes. The points for full
capture for me are conceptual clarity, uniformity (why is a = b
forbidden while a.changeAllMyPrivateState() is not?), and simplicity
(of the language, not of the implementation - less rules = good ;).
But as I have said in past discussions, I believe the need for "full"
closures is much less felt in Java than in other languages because
closures are going to be syntax sugar for full classes anyway, so you
can always resort to an inner class if you want to hold state, at the
cost of some extra verbosity (as compared to lambdas). Not ideal, but
not terrible either, imho.

Cheers,
Alessio