tag:blogger.com,1999:blog-8678405.post4732168631945547358..comments2023-09-02T15:54:52.482+01:00Comments on Ricky's technical blog: Why Java Needs Closures (It Already Has Them)Ricky Clarksonhttp://www.blogger.com/profile/13845104548520132930noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-8678405.post-36222496554219751782009-07-07T21:09:25.454+01:002009-07-07T21:09:25.454+01:00You can also get return values right now in java c...You can also get return values right now in java closures.<br /><br /><a href="http://simonwoodside.com/weblog/2009/7/7/a_little_bit_more_serious/" rel="nofollow">Closures with return values in Java</a>Unknownhttps://www.blogger.com/profile/09012154610658671043noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-56302712329138377452007-10-17T01:24:00.000+01:002007-10-17T01:24:00.000+01:00@Ricky,> So in your proposal, the > interface to i...@Ricky,<BR/><BR/>> So in your proposal, the <BR/>> interface to implement is <BR/>> inferred, but the method name is <BR/>> still present in source. That <BR/>> could be inferred too - I don't <BR/>> think it makes sense to force the <BR/>> name to be present when most use <BR/>> cases won't need the name.<BR/><BR/>No both are inferred for the simple case of a single abstract method<BR/><BR/>> Also, it still doesn't nest, in <BR/>> the case that the inner closure <BR/>> and the outer closure are <BR/>> implementing the same name of <BR/>> method.<BR/><BR/>You can nest by multiple qualification, just like you can say super.super.name(). EG:<BR/><BR/>interface Method1<R, A> { R call( A a ); }<BR/><BR/>interface MyList<E> {<BR/>__MyList<E> filter( Method1<Boolean, E> predicate );<BR/>__...<BR/>}<BR/><BR/>...<BR/>MyList<MyList<Integer>> list = …;<BR/>list.filter method (l) {<BR/>__l.filter method (e) { call.call.return true }<BR/>};<BR/>…<BR/><BR/>I can’t see how you could do the example above in BGGA, which is not to say you can’t (I find the proposal obscure in places). Can you show the equivalent BGGA syntax?<BR/><BR/>RE the obscurity of the return syntax I am not alone in disliking it, EG:<BR/><BR/>http://crazybob.org/2007/02/will-closures-carry-as-much-complexity.html<BR/><BR/>and<BR/><BR/>http://weblogs.java.net/blog/cayhorstmann/archive/2007/04/whats_so_taxing.htmlAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-3469749468380460482007-10-15T11:16:00.000+01:002007-10-15T11:16:00.000+01:00"The main thing it does better is to shorten the s..."The main thing it does better is to shorten the syntax"<BR/><BR/>In the case where only one method is being implemented, yes. Otherwise, an inner class is not actually bad, syntactically.<BR/><BR/>"No everything has a name, since it is an inner class and all the methods have a name"<BR/><BR/>So in your proposal, the interface to implement is inferred, but the method name is still present in source. That could be inferred too - I don't think it makes sense to force the name to be present when most use cases won't need the name. <BR/><BR/>Also, it still doesn't nest, in the case that the inner closure and the outer closure are implementing the same name of method.<BR/><BR/>Wrt your examples of BGGA syntax, the ones that are syntax errors jumped out at me quite quickly.. and I don't think it's too bad that invalid code looks similar to valid code. The arguably difficult points are where two valid pieces of code with differing semantics look identical. For example, taken from virtually any beginner Java programmer:<BR/><BR/>if (x)<BR/>{<BR/>...stuff<BR/>}<BR/><BR/>and<BR/><BR/>if (x);<BR/>{<BR/>...stuff<BR/>}Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-40236255435938376732007-10-15T02:29:00.000+01:002007-10-15T02:29:00.000+01:00@Ricky,> Nothing is being removed. A new > syntax ...@Ricky,<BR/><BR/>> Nothing is being removed. A new <BR/>> syntax is being proposed. It does <BR/>> some things better, but will not <BR/>> replace all inner class usage.<BR/><BR/>The main thing it does better is to shorten the syntax. So why not shorten the syntax of inner classes and not loose really useful stuff that inner classes do and closures don't. That way you don't have to debate whether a closure or an inner class should be used.<BR/><BR/>> Howard, your find.return does not <BR/>> nest. If you have a closure <BR/>> within a closure, and the inner <BR/>> wants to return from the outer, <BR/>> there is no way to disambiguate <BR/>> that, as the outer has no name.<BR/><BR/>No everything has a name, since it is an inner class and all the methods have a name. You may not have had to type the name, i.e. the name may be inferred, but it does have a name.<BR/><BR/>With BGGA things are confusing, given:<BR/><BR/>static int apply({int=>int}, int x) { return f.invoke(x); }<BR/><BR/>what do these do:<BR/><BR/>{int=>int} f1 = {int x=>x * 42};<BR/><BR/>{int=>int} f2 = {int x=>x * 42;};<BR/><BR/>{int=>int} f3 = {int x=>return x * 42};<BR/><BR/>{int=>int} f4 = {int x=>return x * 42;};<BR/><BR/>when used like this:<BR/><BR/>int test() {return apply(fx, 1);} // fx means for all the fs<BR/><BR/>and like this:<BR/><BR/>{int=>int} fTemp = {int x=>apply(fx, x)}; // fx means one for each f<BR/>int test() {return apply(fTemp, 1);}<BR/><BR/>It isn't clear is it? Two of them are syntax errors and they look a lot like the ones that aren't! And the two that aren't syntax errors behave differently!!hlovatthttps://www.blogger.com/profile/07048859648718746436noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-65402688384735864142007-10-13T21:29:00.000+01:002007-10-13T21:29:00.000+01:00casper bang said:"so according to you even anonymo...casper bang said:<BR/><BR/>"so according to you even anonymous inner classes should be written as how the bytecode is emulating it?"<BR/><BR/>No, absolutely not. That would merely be the situation if we didn't have closures already in Java.<BR/><BR/>"Anyway, when people refer to closures they usually have more powerful thinking in mind"<BR/><BR/>Agreed, there are multiple meanings for the word 'closure'. Lambda expression is the main other meaning.<BR/><BR/>The message I'm getting across is that we already have closures, but that they could use some improvement. I think you could only think my opinion is "why must we copy C#?" if you didn't read the words.<BR/><BR/>howard l said:<BR/><BR/>"I don't see why we need an extra construct, why not build upon the existing construct:"<BR/><BR/>BGGA closures do build upon the existing construct, at least in implementation terms, as far as we can speak of an unimplemented spec.<BR/><BR/>"There are many advantages of inner classes that you haven't touched on"<BR/><BR/>I don't doubt that inner classes will be useful alongside BGGA closures, though I personally think aiming toward lambda expressions in general is a good thing. I've written some Scala code recently that uses both inner classes and BGGA-ish closures side-by-side.<BR/><BR/>"A BGGA style closure is a strict sub-set of an inner class - why take away useful features?"<BR/><BR/>Nothing is being removed. A new syntax is being proposed. It does some things better, but will not replace all inner class usage.<BR/><BR/>"The BGGA proposal in places closes over break, continue, and return and in other plaaces doesn't! For example there are two types of return that are distinguished by one ending in a ; and the other not having the ;"<BR/><BR/>It seems more like there are two types - explicit returns with the return keyword, and last-line semi-colon return. I don't think 5; will be a valid return statement anywhere.<BR/><BR/>Howard, your find.return does not nest. If you have a closure within a closure, and the inner wants to return from the outer, there is no way to disambiguate that, as the outer has no name. That's what Neal was talking about wrt Tennent's Correspondence Principle.<BR/><BR/>"But the more important point is that if you want the facility to close over break, etc. then add it to inner classes."<BR/><BR/>Inner classes consist mainly of methods, they're not intended to be blocks of code. They already have semantics for break and continue - I think the principle of least astonishment suggests not adding new semantics to break in existing code (albeit code that currently would not compile). return is even worse to overload. When adding new syntax, such as BGGA closures, you are more free to define new semantics (in this case the semantics of the enclosing code are being retained, a good thing).<BR/><BR/>I may have been too harsh in this comment, no time to review it before getting on a bus!Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-19460289544517370842007-10-12T21:11:00.000+01:002007-10-12T21:11:00.000+01:00The BGGA proposal in places closes over break, con...The BGGA proposal in places closes over break, continue, and return and in other plaaces doesn't! For example there are two types of return that are distinguished by one ending in a ; and the other not having the ;. In my C3S proposal:<BR/><BR/>http://www.artima.com/weblogs/viewpost.jsp?thread=182412<BR/><BR/>I suggest the following to clearly distinguish use cases:<BR/><BR/>boolean find( IntList list, int required ) {<BR/>__list.each( method( value ) { if ( value == required ) find.return true } );<BR/>__return false<BR/>}<BR/><BR/>Note how return is named to indicate what it is returning from. Similarly, break and continue.<BR/><BR/>But the more important point is that if you want the facility to close over break, etc. then add it to inner classes. Don't invent another construct that misses some features out and adds in others. Particularly if the utility of these new features, like closing over break, is of dubiuous value.hlovatthttps://www.blogger.com/profile/07048859648718746436noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-9355556947842808072007-10-12T01:42:00.000+01:002007-10-12T01:42:00.000+01:00"A BGGA style closure is a strict sub-set of an in..."A BGGA style closure is a strict sub-set of an inner class"<BR/><BR/><BR/>Inner classes don't close over the meaning of break, continue, return etc like the BGGA proposal does.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-12076564323588883142007-10-11T23:48:00.000+01:002007-10-11T23:48:00.000+01:00I agree with your sentiment that Java already has ...I agree with your sentiment that Java already has inner classes (closures) and they are really useful. I don't see why we need an extra construct, why not build upon the existing construct:<BR/><BR/>1. You have to declare the free variable final - remove that restriction<BR/><BR/>2. The syntax is long - change the syntax<BR/><BR/>There are many advantages of inner classes that you haven't touched on:<BR/><BR/>1. You can inherit implementation via extending other classes<BR/><BR/>2. You can have fields<BR/><BR/>3. You can have more than one method<BR/><BR/>4. You can call other inherited method or other methods defined within itself<BR/><BR/>5. You can have static data<BR/><BR/>In summary it is a class just like everything else - rather than something that is sort of like a class but has a number of annoying restrictions.<BR/><BR/>A BGGA style closure is a strict sub-set of an inner class - why take away useful features?hlovatthttps://www.blogger.com/profile/07048859648718746436noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-86402447004615015192007-10-11T22:52:00.000+01:002007-10-11T22:52:00.000+01:00Ehhh... so according to you even anonymous inner c...Ehhh... so according to you even anonymous inner classes should be written as how the bytecode is emulating it? That will make for some rather long and complicated parameter lists.<BR/><BR/>Anyway, when people refer to closures they usually have more powerful thinking in mind (continuations, lambda expressions etc.) than the rather loose definition you're adhering to.<BR/><BR/>Not really sure what message you are trying to get across, I suspect it might be "why must we copy C#?" as you mention yourself on the very first line.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-69547925725118467462007-10-11T14:59:00.000+01:002007-10-11T14:59:00.000+01:00My opinion for some time is the same as yours: IDE...My opinion for some time is the same as yours: IDEs in Java should filter away line noise like annonymous inner classes. And when we're at it, the should filter types and annotations away and just show them, when I need them :-)<BR/><BR/>Peace<BR/>-stephan<BR/><BR/>-- <BR/>Stephan Schmidt :: stephan@reposita.org<BR/>Reposita Open Source - Monitor your software development<BR/>http://www.reposita.org <BR/>Blog at http://stephan.reposita.org - No signal. No noise.Stephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.com