Currying and the warning

[Osvaldo Doederlein]

Thanks for the clarification, where is this @Shared annotation specified?
It's not in the closures proposal and I admit to have just guessed its
meaning, I'm not tracking all of JDK7 developments.

A+
Osvaldo

2009/11/20 Zdenek Tronicek <tronicek at fel.cvut.cz>

> 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
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091120/ee3828a6/attachment-0001.html