Currying and the warning

[Zdenek Tronicek]

Hi Osvaldo,

the @Shared annotation says "I am aware that the variable may be  
accessed from many threads". It warns you that you may need a  
synchronization. It is not about hidden costs.

Zdenek
-- 
Zdenek Tronicek
FIT CTU in Prague


Cituji Osvaldo Doederlein <opinali at gmail.com>:

> Hi Neal,
>
> I've just read the new proposal, seems to hit a quite good balance so I hope
> this will finally succeed. Some initial comments:
>
> The proposal doesn't mention support for any kind of transformation. You've
> already explained that MethodHandle doesn't serve as a good basis for
> closures, but I'd like both features to be as... close as possible; and for
> closures, it makes a lot of sense to support currying because this feature
> is highly useful and it wouldn't add any significant complexity (that I can
> see) to the language. The Method Reference facility would also allow to
> curry a common method, this is a simple combination of two steps (creating a
> closure that wraps the method and then currying that closure), but would be
> more efficient if defined/implemented as a single operation (so we can just
> create a single closure that performs the currying, i.e. passing some fixed
> parameters, when delegating to the method).
>
> The _mandatory_ warning for closures that capture non-final/shared vars
> seems too conservative. The motivation should be not freaking people who
> worry about hidden costs, but there's now plenty precedent for that, e.g.
> the silent allocations performed by enhanced-for or autoboxing, or much
> before, inner classes with their synthetic accessors to outer fields/methods
> including private ones. The language spec doesn't require mandatory warnings
> for those. I'm fully favorable to an _optional_ warning, that developers can
> activate when reviewing performance-critical code, such as the many extra
> warnings in the Eclipse compiler or tools like Checkstyle/FindBugs/PMD that
> include many detections of potential performance issues. But IMHO, making
> this warning of captures enabled by default will "taint" closures as
> something expensive, and make it more complex than necessary by requiring
> the @Shared or @SuppressWarnings("shared") annotations. (If the warning is
> optional, I guess we can omit at least @Shared from the spec.)
>
> In a secondary note, item 2 of that warning could be "The variable is not
> the target of any assignment after the closure is defined", which will avoid
> the warning for simple cases like "{ int x; if (a) x = 10 else x = 20; #()
> println(x) }" (not all developers would prefer using ?: here to enforce the
> initialization-in-declaration). Of course, the "after" in "after the closure
> is defined" is not that simple because if the closure is defined inside a
> loop, we can't have assignmaets to the variable before the closure
> definition but inside the loop; but I guess javac can already do the
> necessary flow analysis, should need it for definite assignment.
>
>
> A+
> Osvaldo
>
> --
> -----------------------------------------------------------------------
> Osvaldo Pinali Doederlein                        Visionnaire Virtus S/A
> osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
> Arquiteto de Tecnologia                         +55 (41) 3337-1000 #226
>