tag:blogger.com,1999:blog-741750605858169835.post6413390597692683064..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Evaluating BGGA closuresStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger27125tag:blogger.com,1999:blog-741750605858169835.post-692383384058809852008-03-02T23:40:25.000+00:002008-03-02T23:40:25.000+00:00Come along to JAVAWUG BOF where Stephen will be d...Come along to JAVAWUG BOF where Stephen will be discussing the closure proposal<br /><br />http://jroller.com/javawug<br /><br />Be there in!!!Peter Pilgrimhttp://jroller.com/peter_pilgrimnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-58632209435932259652008-02-25T16:04:54.000+00:002008-02-25T16:04:54.000+00:00What I dislike is how the examples I see are contr...What I dislike is how the examples I see are contrived. the first example could be written much more simply as<br /><br />String str =<br /> someBooleanMethod() ? "TRUE" : "FALSE";<br /><br />or even<br /><br />String str = upperCase(someBooleanMethod());<br /><br />for some reasonable implementation of upperCase().<br /><br />I also think the odd look of the operators could be solved if we go to Unicode source files.<br /><br />Replace<br /><br />int y = 6; <br />{int => boolean} a = {int x => x <= y}; <br />{int => boolean} b = {int x => x >= y}; <br />boolean c = a.invoke(3) && b.invoke(7); <br /><br />with<br /><br />int y = 6; <br />{int ? boolean} a = {int x ? x <= y}; <br />{int ? boolean} b = {int x ? x >= y}; <br />boolean c = a.invoke(3) && b.invoke(7); <br /><br />I'm sorry, but the U+21A6 RIGHTWARD ARROW FROM BAR character is missing in this rss reader. That's what those empty boxes are trying to represent.Eric Jablownoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-40961117188450356282008-02-25T07:34:58.000+00:002008-02-25T07:34:58.000+00:00I think you could just drop wildcards:
http://www...I think you could just drop wildcards:<br /><br />http://www.artima.com/weblogs/viewpost.jsp?thread=222021<br /><br />You could also make closures inner classes, the changed behaviour takes away power and causes problems:<br /><br />http://www.artima.com/weblogs/viewpost.jsp?thread=220920Howard Lovatthttp://www.artima.com/weblogs/viewpost.jsp?thread=182412noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-70299782010872361112008-02-24T03:27:22.000+00:002008-02-24T03:27:22.000+00:00Indukumar: Your point is a key distinguishing fact...Indukumar: Your point is a key distinguishing factor between the different proposals. FCM is really just about filling in the gaps in Java - it doesn't much that is conceptually new (eg. we already have Method in reflection - FCM just makes it more typesafe). The inner methods (closures-like) part of FCM is just a way to write the common one method inner class more neatly.<br /><br />Remi: The prototype is out now - I haven't lost type safety anywhere that I can think of.<br /><br />Elliotte: I actually agree with the sentiment of your reply, but unfortunately I think Java 5 is a bad place to stop and freeze. There are relatively few things we could actually remove (String var[] being the most obvious). Inner classes would need to stay, as they have a different role to closures.<br /><br />For me, the real problem with Java 5 is wildcards - erasure is probably fixable, but we are stuck with the undesirable, complex, wildcard part.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-90456455477391816932008-02-23T18:21:57.000+00:002008-02-23T18:21:57.000+00:00You say that, "Despite this broader debates t...You say that, "Despite this broader debates that surround closures, we must focus on the merits of the individual proposals." but we still can't judge this in isolation. One must consider the overall size and complexity of the language, especially for people who haven't been living and breathing Java for 10+ years.<br /><br />The problem with generics is not only that the syntax and implementation was individually bad. It was that they pushed the language over the threshold where the basics could comfortably be learned and understood in a reasonable amount of time and effort.<br /><br />Every new feature we add to the core language now takes us further down that road, unless we start removing things from Java to offset what we're adding. No closure proposal is acceptable at this point unless we also remove inner classes and other obsoleted constructs. Otherwise Java will sink under its own weight. Frankly, it's been going under since Java 5, and none of the existing proposals address this.Elliotte Rusty Haroldhttp://htp://www.elharo.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-91959266575233645992008-02-22T03:29:06.000+00:002008-02-22T03:29:06.000+00:00I think the syntax can be improved to look more fa...I think the syntax can be improved to look more familiar and less verbose. Why not use a simplified C/C++ function pointer syntax given that Java got most of its syntax from C++. <br /><br />Something like this maybe:<br /><br />boolean* (int) a = (int x) {x <= y}; <br /><br />And this:<br /><br />public U* (T) converter(T* a, U* b, U* (T) c) {<br /> return (T t) {a.invoke().equals(t) ? b.invoke() : c.invoke(t)};<br />}WarpedJavaGuyhttp://warpedjavaguy.wordpress.com/2008/02/21/pointer-syntax-for-java-closures/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-14389175873663080502008-02-21T20:24:22.000+00:002008-02-21T20:24:22.000+00:00Capattar, are someone else who wasn't payiong ...Capattar, are someone else who wasn't payiong attention when generics was developer (in public over many years)? What should your penalty be? Do you have any positive proposals?Mark Thorntonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-56574078850439448212008-02-21T16:08:51.000+00:002008-02-21T16:08:51.000+00:00> The result of implementing generics with eras...> The result of implementing generics with erasure <br />> and wildcards has been a loss of confidence in <br />> Java language change. Many now oppose any and<br />> all change, however simple and isolated. This<br />> is unfortunate, and we must ensure that the next<br />> batch of language changes work without issues.<br /><br />The next batch? No, "you" first of all must ensure that the LAST batch of changes (e.g. generics) works without issues. Only then "you" should be allowed to work on new features.<br /><br />"You" should be treated like schoolchildren. No play in the park and no fun before the homework is done, and done right. Actually, "you" should be grounded for month because of the generics misconduct alone, without closure-TV and closure-telephone. And "you" should get an extra month for not being able to get along with the other closure children in the Java park.Capattarnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-84193447362982072472008-02-21T11:51:29.000+00:002008-02-21T11:51:29.000+00:00Stephen: knowing if a method like actionPerformed ...Stephen: knowing if a method like actionPerformed can be called by another thread later is in my opinion inherent to all instances of ActionListenener. So it's not compatible with a use-site approach but more with a declaration-site approach.<br />Futhermore, declaration site marker is more easy to grasp than use-site one, i think that wildcard is a good example.<br /><br />About single method interface, am i wrong or will you loose the type safety ?<br /><br />RémiRémi Foraxhttp://weblogs.java.net/blog/forax/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16552939474408866622008-02-20T22:18:07.000+00:002008-02-20T22:18:07.000+00:00The main benefit of closures is not in the languag...The main benefit of closures is not in the language itself, but their usage in libraries... There are a huge amount of libraries that would immediately become 'legacies' once the closures come in. In the end we have collections with closures, collections with generics (if we use reified generics), collections with the closures and generics, collections without them (backward compatibility)... I mean is it the way that we want to push Java? And for what purpose, to save a few lines of code writing anonymous inner classes? <br /><br />I personally do NOT want closures in Java.. I like them in Scala and Ruby but NOT in Java. Java has far too much baggage of conventions, idioms and "feel" to add more changes. Just freeze the changes in Java. Move on to better languages.Indukumarnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-44866587839316081522008-02-20T20:17:06.000+00:002008-02-20T20:17:06.000+00:00Cay: Even BGGA will create closures as one method ...Cay: Even BGGA will create closures as one method interfaces. So, maybe we shouldn't be trying to hide that fact from developers. I would say that the majority of Java developers are very comfortable with interfaces. Strengthening their usage makes perfect sense - whereas trying to create a new fundamental program element is far from obvious.<br /><br />Aberrant: The possibility is to remove the whole section of the FCM spec about method types. The result would be that method references and inner methods would always have to be converted on construction to a SMI (single method interface).Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-44766040551810885982008-02-20T19:37:42.000+00:002008-02-20T19:37:42.000+00:00Gregory: If method types (or similar) remain in FC...Gregory: If method types (or similar) remain in FCM, then yes you could write code as you show using generics.<br /><br />Remi: James Gosling seems to be a Sun marketing person these days. His opinions carry too much weight for his day to day Java efforts.<br /><br />With ActionListener, why should all ActionListeners be restricted? I might want to use one in a non-resticted way. The marker interface approach is broken - a use-site approach is what is needed.<br /><br />On function types, I do believe that named function types ought to be possible, and I hope to blog on that soon.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-68005813096629359422008-02-20T16:32:58.000+00:002008-02-20T16:32:58.000+00:00Just to clarify, the control invocation syntax all...Just to clarify, the control invocation syntax allows one to elide the superfluous declaration of the function type when there is only one of them, making things like<br /><br />withLock(l) {<br /> ...<br />}<br /><br />indeed appear very natural and Java-like. I do believe that the participation of James Gosling will ultimately provide a direction that is closer to what we Java-folks like so much about the language. In short, one can say that James is the so called benevolent dictator and so far has served his post very well, as is evidenced by the success of Java as a language, and as a platform.goodOverviewhttp://goodOverview@yahoo.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-85767367155015681462008-02-20T16:10:53.000+00:002008-02-20T16:10:53.000+00:00Good overview of the current debate. I agree that ...Good overview of the current debate. I agree that syntax should probably be re-examined. According to a Google video of Neal Gafter presenting the BGGA proposal, the control invocation syntax arose as a result of collaboration with James Gosling. I really would hope to see a consensus formed around this, so that Java can acquire some means of making anonymous inner classes easier to use, and I personally like the notion of abstracting over control statements offered by BGGA. I can see that you're making an honest effort to improve Java, but lately I've been getting the feeling that some of the anti-change folks have basically migrated to some other language and perhaps feel that Java should just stagnate and die.<br /><br />I sincerely hope that those folks would not have a voice in the debate.<br /><br />Thanks for your efforts.goodOverviewhttp://goodOverview@yahoo.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-56224257294788507012008-02-20T16:09:50.000+00:002008-02-20T16:09:50.000+00:00I like FCM as it stands now, what exactly would yo...I like FCM as it stands now, what exactly would you be removing? Method types? Could you give an example of how inner methods, method references and method literals would look without method types?<br /><br />thanks,<br /><br />CollinAberranthttp://aberrantcode.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-40662099075678614902008-02-20T16:05:28.000+00:002008-02-20T16:05:28.000+00:00Very nice summary. My reaction: If that's all ...Very nice summary. My reaction: If that's all that's wrong with BGGA, then let's get on with it and add BGGA closures to Java. <br /><br />- Strange syntax? What was strange yesterday is commonplace tomorrow. Ask the folks who use Ruby, XPath, JPQL, etc.<br /><br />- Functions aren't object-oriented? So what? They are useful, and it is a pain to fake them with objects of single-method anonymous classes. <br /><br />- Non-local return? I agree that part needs a bit more work. Sometimes you want it, sometimes you don't, and errors should be found at compile time. I played with the current BGGA prototype, and it does have a mechanism for compile-time checking. I would like to see more blogs that come up with creative solutions for this issue, rather than the usual handwringing about >= and =>.Cay Horstmannhttp://horstmann.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-29378399873908552122008-02-20T15:38:52.000+00:002008-02-20T15:38:52.000+00:00I heartily recommend to the other commenters Steph...I heartily recommend to the other commenters Stephen's note that whining about BGGA syntax isn't very productive, because it can be changed.<br /><br />Closures are easily complex enough to need crucial issues sorted out first, before we dig down into syntax considerations.<br /><br />Personally I consider the two real issues at this point:<br /><br />1. function types. (The notion that {int, int => void} is just as legal a type as 'String'). Introducing them turns java into a structural/nominal typing hybrid, and that's an enormous change. Right now -any- type in java has a 'home' with javadocs and a place where you can easily run 'come from' queries in your editor. function types don't have that, and they have no proper namespace either. It's big, in other words. Do we really want to go there? As Stephen said, FGM has them but can live without them, and CICE doesn't have them but it can be faked a little by adding a new package with a bunch of Function interfaces that you can choose from.<br /><br />2. 'long' returns. They are part of BGGA. They can be added without any problem to the CICE proposal, using the same exception-based mechanism BGGA uses, and e.g. the same syntax used by long breaks/continues (return someLabel: theReturnValue;). This is normally a minor consideration, but as Stephen correctly identified in this post, the fallout of doing it right is considerable, and really requires some big changes to get it right (such as turning every statement into an expression).<br /><br />Lastly, there are two things to keep in mind with this closure stuff:<br /><br />1. these proposals are not written in stone. If function types are out and long returns are in, you can take any of the proposals and add or remove features as needed until you have just that. Don't get hung up on syntax, that really isn't the issue (yet).<br /><br />2. Don't consider closures as its own little world. Some of the java5 features didn't make a whole lot of sense on their own but the package of all java5 features supported each other and made each individual change better. autoboxing is so-so, but together with generics, it makes a lot more sense. The foreach loop is a lot less magical when Iterators have a generics type. Think about it - without generics, foreach would be virtually useless.Reinier Zwitserloothttp://https://tipit.to/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-57848727811930552382008-02-20T15:32:42.000+00:002008-02-20T15:32:42.000+00:00Converter is a nice example. It both demonstrates...Converter is a nice example. It both demonstrates the peculiarity of the syntax compared to plain old Java, and shows off how to handle poles when mapping sets (e.g., how to handle "blowing up" when approaching divide-by-0 case).<br /><br />This is a very elegant, enlightening post!B. K. Oxley (binkley)http://binkley.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-78267610355278732382008-02-20T15:21:10.000+00:002008-02-20T15:21:10.000+00:00whatever: It would be interesting to pursue the id...whatever: It would be interesting to pursue the idea of converting all Java statements to allow them to be expressions. I suspect that it isn't actually pratical - and it would definitely change the feel of Java.<br /><br />Arman: You misunderstood the "simple and isolated" comment, which was a separate point to closures (ie. people are now objecting to any change, even something like a new string literal form.<br /><br />Frederic, Bharath, Mikael: Thanks for the kind words.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-58519730866743890562008-02-20T08:27:11.000+00:002008-02-20T08:27:11.000+00:00Great writeup Stephen. I believe you and Josh have...Great writeup Stephen. I believe you and Josh have more in common than you might think. I also believe that you should cooperate with Josh to create a single strong proposal to counter BGGA.<br />Understanding that complexity will only benefit the really interested developers is the key piece of information here. Both you and Josh have that same view and it would be a shame if BGGA became the implemenation just because there were two individually competing, but better, proposals.Mikael Grevnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-39279645726899527362008-02-20T03:24:03.000+00:002008-02-20T03:24:03.000+00:00Excellent. A fair evaluation of the BGGA proposal....Excellent. A fair evaluation of the BGGA proposal. Thanks in particular for highlighting its ugly syntax alien to Java. It isn't a trivial issue, mind you. This paragraph should have been in font size 32, bold:<br /><br /> int y = 6;<br /> {int => boolean} a = {int x => x <= y};<br /> {int => boolean} b = {int x => x >= y};<br /> boolean c = a.invoke(3) && b.invoke(7);<br /><br />"Following =>, <= and >= can get very confusing. It is also a syntax structure for parameters that is alien to Java. "Bharath Rhttp://infinitescale.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-17433102712704202902008-02-20T00:18:47.000+00:002008-02-20T00:18:47.000+00:00Hi stephen, nice post.
About the benelovent dicta...Hi stephen, nice post.<br /><br />About the benelovent dictator, Java has Gosling<br />see http://blogs.sun.com/jag/entry/closures,<br />its last blog about closure.<br /><br />In my opinion, Java is currently in a transition phase from a cathedral organization to a bazaar one, it takes time and the way closure will or will not be integrated in jdk7 can be seen as a test of the new organisation.<br /><br />You are right about statement & expression, Java is neither Scala nor JavaFX.<br /><br />About non-local returns, one can decide to add a super class, non accessible to Java but accessible a bytecode level, to Throwable and makes NonLocalTransferException inherits from that class.<br />Furthermore, ActionListener is a listener, a callback that can be called by another thread that the one that creates the listener.<br />Having an interface that marks this kind of objects is a good idea.<br />I just think that RestrictedFunction can be renamed but the concept behind is interresting because it leads to better code.<br /><br />Functional programming: BGGA function types are translated to generics so it doesn't add complexity to the type system.<br />But it clearly adds a level of indirection directly into the programmer mind :)<br /><br />If you find a clean way to specify such function types using names, I will cast my vote for a mix between BGGA and FCM. <br /><br />RémiRémi Foraxhttp://weblogs.java.net/blog/forax/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-7705466784141654832008-02-19T19:45:12.000+00:002008-02-19T19:45:12.000+00:00I've enjoyed each of your posts comparing clos...I've enjoyed each of your posts comparing closure proposals and have already voted for FCM. :-) A question arose today about how FCM closures would interact with generics. Could do something like ask for a constructor for some implementation of an interface?<br /><br />E.g.<br />public void doSomething(#(T()) ref){...}Gregory Kickhttp://kickstyle.net/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-12629084725152234002008-02-19T19:07:34.000+00:002008-02-19T19:07:34.000+00:00WOW!
What a nice and clear presentation of BGGA is...WOW!<br />What a nice and clear presentation of BGGA issues.<br />Bravo!Frederic Simonhttp://freddy33.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-23158899404814204362008-02-19T18:29:31.000+00:002008-02-19T18:29:31.000+00:00How's introducing closures a "simple and ...How's introducing closures a "simple and isolated" change? Instead of ensuring "that the next batch of language changes work without issues," current issues should be addressed first. The way I see it, if 40% of the community are against closures, then none of the competing proposals should go through; at least not in their current form. If there's an overwhelming demand to address current problems (e.g. generics), then these should be given first priority. What we have instead, is various parties pushing their own agenda.Arman Sharifhttp://jreform.sourceforge.netnoreply@blogger.com