Currying and the warning

[Zdenek Tronicek]

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
>>>
>>>
>>
>>
>>
>