tag:blogger.com,1999:blog-741750605858169835.post2320812946937833867..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: FCM closures - options withinStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-741750605858169835.post-57842195670240326982008-03-03T22:24:34.000+00:002008-03-03T22:24:34.000+00:00I do think inner methods that behave differently t...I do think inner methods that behave differently than inner classes are like boxing and function types even more like boxing, e.g. in BGGA:<br /><br />pool.execute( { => System.out.println( "Hello" ); } );<br /><br />is OK, but:<br /><br />{ => void } printer = { => System.out.println( "Hello" ); }<br />pool.execute( printer );<br /><br />Isn't because the closure got boxed into a synthetic function interface on the first line and the second line is looking for a Runnable. In the first version the closure is boxed into a Runnable.<br /><br />This boxing behaviour is why you need to have the RestrictedFunction interface, to turn off the normal behaviour. I think a better alternative to have closures that are objects - just like everything else. The changed behaviour simply removes power, you can't inherit, and causes problems with interoperation between existing APIs and closures.<br /><br />Remember with the behaviour of this we are only talking about what happens in the case when there is an ambiguity. These ambiguities are rare, this is a double reason to go with the existing practice of having to qualify enclosing references. Imagine someone debugging some code and they get one behaviour from an inner class and a different behaviour from an inner method and that the bug is rare, so they are not familiar with the two behaviours. This is going to be really tough to debug and really tough to teach.Howard Lovatthttp://www.artima.com/weblogs/viewpost.jsp?thread=182412noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-19095725108802520932008-03-02T11:24:11.000+00:002008-03-02T11:24:11.000+00:00Howard: I think you may have references and litera...Howard: I think you may have references and literals the wrong way around. The use of a 'method' keyword instead of # is a valid syntax alternative we should consider. I don't think 'boxing' is the right term for BGGA or FCMs approach, as the conversion is solely from the literal form on construction. I don't agree with optional parameters in Java.<br /><br />On 'this', I believe that if the calling code includes the class name to be implemented then it is OK for 'this' to refer to that class. However, if the class name is not mentioned (as with #), then 'this' should refer to the lexical class.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-17009196636882262472008-03-02T11:14:32.000+00:002008-03-02T11:14:32.000+00:00Mark: Yes, your example is a pain. But its really ...Mark: Yes, your example is a pain. But its really more an example of the poor implementation of generics (if the list retained its type then the contains method would also convert to a Runnable)<br /><br />Paul: I understand the desire to avoid a new symbol, but this doesn't work for me. instanceof is all about classes and types, not references.<br /><br />Faith: I don't believe that the computer science feature 'closures' requires control invocation - I may be wrong of course. Part of the purpose of this post is to empahsise that the reference/literal parts could be taken separately, and that means adding it to another proposal if desired.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-35145801744694491802008-03-02T09:33:48.000+00:002008-03-02T09:33:48.000+00:00Method references / literals are nice. But I won&#...Method references / literals are nice. But I won't buy any closures proposal without full "control invocation" features. Don't call your proposal a closures proposal, if this feature is not included. Perhaps it would be best not to compete with BGGA and specify a new proposal just for method references / literals.Fatih Coskunhttp://coskunscastle.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-39636128543376293042008-03-01T00:35:44.000+00:002008-03-01T00:35:44.000+00:001. References
Good idea - there is also a long st...1. References<br /><br />Good idea - there is also a long standing RFE on the Sun database for this<br /><br />2. Literals<br /><br />Probably not worth the trouble - you can use an inner method just as easily<br /><br />3. Inner methods<br /><br />I have suggested the method keyword:<br /><br />http://www.artima.com/weblogs/viewpost.jsp?thread=182412<br /><br />Your example using a method keyword is:<br /><br />ActionListener lnr = method( ActionEvent ev ) {<br />__...<br />};<br /><br />You could also add some type inference to this:<br /><br />ActionListener lnr = method( ev ) {<br />__...<br />};<br /><br />or:<br /><br />declare lnr = ActionListener.method( ev ) {<br />__...<br />};<br /><br />For right to left inference. Type inference could be added to any of the proposals.<br /><br />Also I have suggested that the behaviour of inner methods should be as inner classes. In particular an unqualified this in the case of ambiguity refers to the inherited class not the enclosing class. I think different behaviour from inner classes will be confusing and leads to problems. The closures require boxing for example in BGGA to play with existing APIs. An OO language should have objects, full stop. Lets not introduce any more autoboxing.<br /><br />For non-local returns I have suggested named returns, see above URL or:<br /><br />http://www.artima.com/weblogs/viewpost.jsp?thread=220920<br /><br /><br />4. Method types<br /><br />Not worth the trouble, just add generic interfaces to java.lang:<br /><br />interface Method0 { R call(); }<br />interface Method1 { R call( A1 a1 ); }<br />...<br /><br /><br />5. Control invocation<br /><br />The simplest option is to make the () optional when calling a method (provided that it isn't ambiguous), e.g.:<br /><br />withLock lock, method{<br />__...<br />};Howard Lovatthttp://www.artima.com/weblogs/viewpost.jsp?thread=182412noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-89846148891498717572008-02-29T03:50:16.000+00:002008-02-29T03:50:16.000+00:00What do you think about this syntax?
Method m = i...What do you think about this syntax?<br /><br />Method m = instanceof Integer.valueOf(int);<br /><br />No new keywords or tokens.Paul Benedictnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-44471345056166292012008-02-28T23:39:04.000+00:002008-02-28T23:39:04.000+00:00Stephen,
Actually it seems to return true at the ...Stephen,<br /><br />Actually it seems to return true at the moment - the expression Foo#bar() is translated to an instance of java.lang.reflect.Method in both the call to add() and the call to contains(). <br /><br />However, once generics are handled properly, I'd expect Foo#bar() to be translated to a Runnable in the first case - since we're calling add(Runnable) - but still to<br />a java.lang.reflect.Method in the second case - calling contains(Object) - as such, I think the result would be false.<br /><br />MarkMark Mahieuhttp://markmahieu.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-69871463111411870562008-02-28T23:23:09.000+00:002008-02-28T23:23:09.000+00:00Stefan: Agreed that there ought to be ways to make...Stefan: Agreed that there ought to be ways to make control invocation independent of method types.<br /><br />Mark: Your example would return false at present, however that is a question of whether method references should define equals and hashcode. I suspect that the final spec will need to. Certainly, in your example it makes sense for the underlying generated inner class to be a singleton.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-22593899994139505282008-02-28T23:02:10.000+00:002008-02-28T23:02:10.000+00:00Stephen,
If I've understood the proposal and ...Stephen,<br /><br />If I've understood the proposal and your examples correctly, once the prototype deals with generics better the following code will compile and output 'false' when run - is that correct? I expect that would result in a great deal of confusion if so...<br /><br />Mark<br /><br /><br />import java.util.*;<br /><br />public class Foo {<br /> <br /> public static void main(String[] args) {<br /> <br /> List methods = new ArrayList();<br /> methods.add(Foo#bar());<br /> System.out.println(methods.contains(Foo#bar()));<br /> }<br /> <br /> public static void bar() { }<br />}Mark Mahieuhttp://markmahieu.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-31957577128977812482008-02-28T23:00:27.000+00:002008-02-28T23:00:27.000+00:00Thanks for the insights, Stephen.
I would like to ...Thanks for the insights, Stephen.<br />I would like to add on the JCA topic a bit. Although, the current proposal bases on method types, in my opinion, it would be easy to detach JCA from closures completely. As a JCA only can take one void-return block, introducing a separate definition syntax and an implicit block invocation syntax would provide the same abilities. Simple idea:<br /><br />public static void forEach(K, V : Map map) {<br />´ ´ for (Entry entry : map.entrySet()) {<br />´ ´ ´ ´ do(entry.getKey(), entry.getValue());<br />´ ´ }<br />}<br /><br />Apart from how to implement control abstraction, I just had a discussion yesterday on an argument that I did not think of before, even historically being a Smalltalk guy: seeing that Java has about 50 keywords currently (plus operators and so on), it seems interesting to see that Smalltalk code in most cases is much more readable/elegant than Java, only having about a handfull of keywords and -symbols. The main reason is that Smalltalk does not have control structures for computations but actually allows control abstractions by applying messages (methods) and blocks (closures).Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.com