> Note that the definition of 'closures' is not synonmous
> with anonymous code blocks. Other languages use the term
> 'lambda expression' to mean an anonymous block of code;
> there's some strong opinions against confusing the
> semantic concept of a closure with the syntactical
> structure used for defining an in-line function.
>
> There's more discussion on this, including input from
> other language designers and functional systems, hosted on
> EclipseZone
>
> http://www.eclipsezone.com/eclipse/forums/t86911.html
>
> Alex.

he he...funny thread. All the hot heads of the PL community gathered together and they can not give a clear definition for one of the basic constructs of their favorite tool.

How do they expect the rest of the world to get functional programming?

That's precisely why using the term 'closure' is a bad idea. Something like an anonymous function is unambiguous, avoids confusion, and doesn't result in disagreements as to what it should mean. In fact, anything else is better than closure :-)

Alex.

My great hope is that folks responsible for the future of Java restrain themselves from adding unnecessary and cumbersome symbols. (i.e., '=>' and things of that nature)

Why can't we just rewrite the closure as such:

{ (int x, int y) x + y }

or

{ int x, int y { x + y } }

or better yet, why not simply simulate the traditional method call, thereby underscoring the fact that closure is essentially a nested method, thus its parameter declaration and scoping should resemble the familiar method syntax.

(int x, int y) { x + y }

Why introduce all these new symbols? Java is a clean language, adding two-character symbols for something which can be easily expressed using parenthesis or braces is not buying any "character savings", and does not facilitate familiarity for newcomers.

Whats with the symbol love?

{ int x, int y => x + y }

In my opinion, its not clean. If one were to use the colon, it might be better, but then again, why not just use the tried and true method declaration syntax?

I've posted this to Neil Gafter's blog, but apparently either the moderation system malfunctioned, or this proposal
didn't pass the censor.

I have some doubts about the propositions, it looks for me inconsistent.

What will hapen if I define code like that inside my method:


void initListeners() throws SomeException {


void addListener(ItemSelectable is) {
is.addItemListener(
{ ItemEvent e => if (...) throw new SomeException(); }
)
}
}


The problem is, that closure may be executed after the end of execution of the enclosing method.

If the closure will be executed after the method
initListeners() will be finished, what will happen to the SomeException thrown from inside the closure?

It can not be just thrown to the Swing's API, because it didn't expect the checked exception of this type after calling itemStateChanged method from ItemEventListener interface.

Is there any planned way to inform compiler that a specific closure can not throw Exception (or return a value), because it might be executed after the end of execution of enclosing method? I do not see a clear way to enforce that rules by the compiler.

> Is there any planned way to inform compiler that a
> specific closure can not throw Exception (or return a
> value), because it might be executed after the end of
> execution of enclosing method? I do not see a clear way to
> enforce that rules by the compiler.

Yes, there is a way to do that, and there are a couple of examples in the specification that show how it is done. That's the point of the "throws" generic type parameter.