The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

Articles Forum
Considering Closures for Java

19 replies on 2 pages. Most recent reply: Feb 10, 2007 11:33 PM by Neal Gafter

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 19 replies on 2 pages [ « | 1 2 ]
Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Considering Closures for Java Posted: Dec 22, 2006 2:33 AM
Reply to this message Reply
Advertisement
> 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?

Alex Blewitt

Posts: 44
Nickname: alblue
Registered: Apr, 2003

Re: Considering Closures for Java Posted: Dec 23, 2006 2:58 AM
Reply to this message Reply
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.

Ired Sedl

Posts: 2
Nickname: ired
Registered: Dec, 2006

Re: Considering Closures for Java Posted: Dec 27, 2006 12:20 PM
Reply to this message Reply
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.

Marcin Sarniak

Posts: 1
Nickname: saren
Registered: Jan, 2007

Re: Considering Closures for Java Posted: Jan 1, 2007 3:50 PM
Reply to this message Reply
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.

Neal Gafter

Posts: 12
Nickname: gafter
Registered: Oct, 2003

Re: Considering Closures for Java Posted: Feb 10, 2007 11:33 PM
Reply to this message Reply
> 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.

Flat View: This topic has 19 replies on 2 pages [ « | 1  2 ]
Topic: Refactoring the EJB APIs Previous Topic   Next Topic Topic: Spring Clustering with Terracotta
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use