Currying and the warning

[Osvaldo Doederlein]

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/d49dc13d/attachment.html