Effectively final effective?

[Reinier Zwitserloot]

On Thu, Feb 25, 2010 at 10:00 AM, Peter Levart <peter.levart at marand.si>wrote:

> For example, how do you find this:
>
>  final *volatile Type1 result1 = &null;
>  final *Type2 result2 = &null;
>   doSomeApi(#(){ *result1 = someComputation(); *result2 =
> otherComputation(); });
>  doSomethingWith(*result1, *result2);
>
>
It's still more than a month until April 1st.


Introducing Both * and & makes java look like C which is certainly going to
cause the sky to fall down. It's purely a perception problem of course, but
a perception problem is still a problem. Ignoring the C-ishness of it,
You're now committing both prefix * and prefix & for this use, which means
not only that other future features can no longer use it, but also that
parsing java code becomes more complicated, resulting in syntax errors
become more obscure (as its harder for the compiler to figure out what you
did mean). All this to avoid some minor effort for a use case that's
relatively rare and should always be treated with much care. Hence I judge
this proposal as a fantastically bad idea.

NB1: The minor workaorund is to use AtomicReference/AtomicInteger and
friends.

NB2: Without an explicit 'safe / unsafe' closure concept, turning local
variables into heap-allocated non-thread safe variables is a major change
and something that you should always be careful with. *with* an explicit
'safe / unsafe' closures concept, the solution is of course to state that
safe closures may mutate variables from their enclosing scope, and for the
compiler to sort out how to make it happen. This idea is therefore either
dangerous or unnecessary, depending on if safe/unsafe closures somehow make
it into lambda-dev.