tag:blogger.com,1999:blog-741750605858169835.post234688588484440007..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Comparing closures - CICE, BGGA and FCMStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-741750605858169835.post-38723395488544055202007-03-02T13:20:40.000+00:002007-03-02T13:20:40.000+00:00As far as I can see, none of these proposed change...As far as I can see, none of these proposed changes actually introduces any new functionality. If I've got that right, then their only effect is to introduce new, alternate, spellings, for existing functionality. How can that possibly be a good thing?Blakenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-80831138519756118942007-03-01T20:20:24.000+00:002007-03-01T20:20:24.000+00:00All these examples are too much typeing. In my op...All these examples are too much typeing. In my opinion closures and type saftey are like oil and water. There <i>are</i> ways to make them mix, but ti takes a whole lot of effort, often too much. I want less typing, like<br /><br />Example 1<br /><br />button.actionPerformed = { handleButtonPress(it) }<br /><br />or alternately<br /><br />button.actionPerformed = &handleButtonPress<br /><br />Example 2<br />int multiplier = 3<br />mult = { it * multiplier }<br />int result = mult(6)<br /><br />Dynamic languages have the advantage of allowing a lot of shortcutting when there is only one sensical way that a statement can be interpreted. The burden is placed on the compiler and not the end user hand encoding the mystic incantation of unreadable type code. These code samples are in Groovy BTW.Danno Ferrinhttp://shemnon.com/speling/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-77034411515495542442007-03-01T17:33:28.000+00:002007-03-01T17:33:28.000+00:00@Brian, you cannot hand on private methods to a cl...@Brian, you cannot hand on private methods to a class outside of the defining one. Although allowing method references, one has to respect their accessibility. Not doing so would violate a core rule within Java and OO. Having inner methods, means are given for wrapping and passing (as the inner method will operate in the context it was constructed).Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20102500981737699092007-03-01T16:18:38.000+00:002007-03-01T16:18:38.000+00:00I like the concept, but please don't use '...I like the concept, but please don't use '#'. The justification based on javadoc is unconvincing; javadoc is borrowing from the HTML syntax for an anchor reference and it doesn't make sense here. <br />Borrowing from C, this syntax looks good:<br /><br />button.addActionListener(&handleButtonPress(ActionEvent));<br /><br />I'm not sure how you generalize that to inline functions, but maybe we don't need anything more. Writing a private method each time you need to do this isn't so bad and would be a big improvement over anonymous inner classes.<br /><br />If we actually want to do lambdas, the BGGA syntax is nicest so far.Brian Slesinskyhttp://slesinsky.org/brian/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20550996253127931442007-03-01T15:15:36.000+00:002007-03-01T15:15:36.000+00:00@Erik, Sorry, I see it now!!! Its also fixed :-)@Erik, Sorry, I see it now!!! Its also fixed :-)Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-4821674105364001502007-03-01T13:44:34.000+00:002007-03-01T13:44:34.000+00:00I am confused. Why is "handleButtonPress"...I am confused. Why is "handleButtonPress" still relevant in example 2? It is only about multiplication. Right?Erik van Oostenhttp://day-to-day-stuff.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-14939377327292347622007-03-01T13:07:05.000+00:002007-03-01T13:07:05.000+00:00@Erik, No, not a cut-and-paste, I'm simply cal...@Erik, No, not a cut-and-paste, I'm simply calling the method from example 1 (without copying it again and again into each example).<br /><br />@Tom, I see the concern over closure-conversion leading to objects not being equal. I'm just not sure its that important.<br /><br />Method types don't relate to j.l.r.Method. As we wrote the proposal we investigated various ideas of how to integrate them, but in the end we felt that the proposal was simpler and clearer without a link.<br /><br />As for whether to restrict to interfaces, we wanted to be able to handle the two cases from CICE - initValue() on ThreadLocal, and removeEldestEntry() on LinkedHashMap. CICE proposes a horrible hack of artificial abstract classes to allow these methods to be overridden.<br /><br />@Alex, #(int,String return int) is a syntax we did consider. In the end we went with a syntax that matches the order of things in a method declaration. This alternate syntax does have some appeal however.<br /><br />@Carsten, #(int{int}) isn't one we considered, and doesn't appeal to me right away. Your symmetry argument has some appeal though.<br /><br />@Damon, I've never knowingly had a need for currying, but obviously others do. As such we put it in the open issues section. If you've any ideas of a syntax that would work then let us know.<br /><br />@Noah, I'll try and reply on your blog when I have time :-)Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-70332173334154649242007-03-01T12:57:53.000+00:002007-03-01T12:57:53.000+00:00Example 2 mentions "handleButtonPress" a...Example 2 mentions "handleButtonPress" again. Copy/paste mistake?Erik van Oostenhttp://www.day-to-day-stuff.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-59352761870762639582007-03-01T07:42:20.000+00:002007-03-01T07:42:20.000+00:00Why not this #(int return int)? - though I find &#...Why not this #(int return int)? - though I find '#' not appropriate for Java<br /><br />#(int(int)) mult = #(int value){return value*multiplier;};<br /><br />simply lacks the symmetry of the BGGA variant, what about this:<br />#(int{int}) mult = #(int value){return...<br />or #( (int,double) ) for void with int and double args, etc.<br /><br />The '#' can be replaced by the '.' if we accept to reference no-args like toString() by toString(void). Omitting the () won't work as you'd collide with a variable/member toString.Carstenhttp://www.saager.org/2006/12/23/159.htmlnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-8019317741134439572007-03-01T03:51:57.000+00:002007-03-01T03:51:57.000+00:00Not to completely plug my own blog, but I've b...Not to completely plug my own blog, but I've been working on an informal mixins proposal, and FCM cleans it up quite a bit. I'd be very interested in your comments.<br /><br />Links:<br />http://jroller.com/page/noah/?anchor=java_mixins<br />http://jroller.com/page/noah/?anchor=java_mixins_revisitednoahhttp://jroller.com/page/noahnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42241747010408157752007-03-01T03:08:32.000+00:002007-03-01T03:08:32.000+00:00Thanks Stephen, this helps a lot. I like FCM a lo...Thanks Stephen, this helps a lot. I like FCM a lot but I'm not terribly comfortable with the method-type syntax with respect to the return. I understand the motivation to echo a function signature and leave things in their respective places, but I still find it a bit jarring on the examples here and in the proposal. <br /><br />One crazy idea I had was to reuse the return keyword to make it a bit more descriptive: #((int,String) return int) or even drop the parens around the params which seem unnecessary: #(int,String return int). In void cases, you could even drop the return altogether: #(int,String).Alex Millerhttp://tech.puredanger.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-41347060124729489342007-03-01T02:56:21.000+00:002007-03-01T02:56:21.000+00:00Thanks for the review.
I think method reference l...Thanks for the review.<br /><br />I think method reference literals should be in Java, just to have a non-reflection (non-String) way of getting at them if needed. But here's something to watch out for if you do "closure conversion":<br /><br />ActionListener listener = this#handleButtonPress(ActionEvent);<br />#(void(ActionEvent)) methodTyped = this#handleButtonPress(ActionEvent);<br />// Now listener != methodTyped even though they look like they are a reference to the same thing.<br />// I think this is why C# forced the "new DelegateType" syntax.<br /><br />Also, how do method types relate to java.lang.reflect.Method?<br /><br />Also, I think BGGA doesn't prohibit the ability to get a Method instance via reference literals (such as with your nicely proposed "this#handleButtonPress(ActionEvent)" syntax).<br /><br />Another comment: Single-abstract method classes might be more likely to want "this" to be the newly instantiated object. If you want "this" to be the outer class, then I think it's probably better to stick to interfaces like with BGGA. (Understanding that Object itself has some methods, but they'd be less tempting to use and therefore less likely to be confusing.)Tom Palmernoreply@blogger.com