The Artima Developer Community
Sponsored Link

Articles Forum
Considering Closures for Java

19 replies on 20 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 20 pages [ « | 1 ... 15 16 17 18 19 20 | » ]
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
Advertisement
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.

Flat View: This topic has 19 replies on 20 pages [ « | 15  16  17  18  19  20 | » ]
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