Currying and the warning

[Neal Gafter]

No, it was not in the previous proposal.  It was in the prototype.

On Fri, Nov 20, 2009 at 9:18 AM, Zdenek Tronicek <tronicek at fel.cvut.cz>wrote:

> I think it is not specified anywhere now. But the same annotation was
> already in the previous proposal.
>
> Z.
>
> --
> Zdenek Tronicek
> FIT CTU in Prague
>
>
> Cituji Osvaldo Doederlein <opinali at gmail.com>:
>
>  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/ccb0e5bb/attachment.html