tag:blogger.com,1999:blog-741750605858169835.post71785043108347692..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Java language - anonymous methods (CICE)Stephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-741750605858169835.post-63039115710075268862007-02-22T01:06:23.000+00:002007-02-22T01:06:23.000+00:00I too am not a fan of the -> notation. Reminds ...I too am not a fan of the -> notation. Reminds me of traumatic Perl experiences I am trying to block out. :)<br /><br />Dr.E<br />Appetizing Java Programming Report:<br />http://www.turingshop.com/reports/01Java/DoctorEternalhttp://black-hat-java-programming.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-12191159721291896082007-02-12T23:54:06.000+00:002007-02-12T23:54:06.000+00:00@Stefan, Sorry it wasn't clear that it wasn...@Stefan, Sorry it wasn't clear that it wasn't just SAMs.<br /><br />I have made the point elsewhere that CICE doesn't compete with BGGA in what it is trying to achieve. Its easy to get into a semantics debate about what is and isn't closures.<br /><br />I am trying to move towards a counter-proposal to BGGA. But I don't want to publish the next step until I've thought about it a little more. Because, I do agree that being able to add language extensions should be a goal too. ie. this blog post only represents half the picture formulating in my brain.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-66548453265881260182007-02-12T22:49:13.000+00:002007-02-12T22:49:13.000+00:00"This means that you can override swing adapt..."This means that you can override swing adapters like MouseAdapter"<br />Ok, that is not made clear nor stated in the post, if I can trust my eyes. Maybe, you should have shown this as an example. I cannot tell about the situations, where one only wants to override one of many methods in an adapter. From my experience, this is very seldom the case (for non-SAMs).<br />Comparing CICE (or ColeCICE) with closures in my opinion is otiosely. They target different audiences. While CICE only tries to make existing anonymous classes easier to use, closures bring new features into Java (and, of course, more obstacles to deal with). Maybe I'm too indulged in Smalltalk.<br />What about a counter proposal on closures taking all the things in which you miss or out that annoy you. There is too much fiddling around with little changes, which do not provide a big step forward but introduce new syntax restricting future enhancement possibilities. Introducing new stuff just to "save keystrokes" or "make it more readable" are nice, but don't push a language forward. If it were for that, we would no longer be using Java for enterprise software development, but maybe Ruby, Groovy, or Scala.<br />The neat thing on closures is its potential to allow language extensions like functionality to be handled as API issue, rather than having to change the language's syntax over and over again. Maybe it would be better to introduce some closure type, as for documentation, or method-accessors to match closures with signatures or to define "method types". I thought about what name I would give a function type like {String=>int}, but couldn't find something useful, so maybe it's better to keep anonymous for not implying a semantic (e.g. valueOf) the actual closure will not have.<br /><br />Sorry, for dumping my brain on your blog. I did not mean to convince you on closures, but tried to put another opinion to your thoughts. Hope it's somewhat conducive and not annoying only.Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-55638608727160584782007-02-12T20:34:38.000+00:002007-02-12T20:34:38.000+00:00@Stefan, This differs from CICE because it specifi...@Stefan, This differs from CICE because it specifies the method name being implemented. This means that you can override swing adapters like MouseAdapter, and the thread local example without needing arbitrary abstract classes. In other words, you're not limited to SAMs.<br /><br />On the FP point, I'm not disputing that closures are neat in many ways, I'm just questioning whether they are appropriate for Java. I haven't made up my mind yet, and I suspect my next post will emphasise that.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-25256036233179269332007-02-12T18:07:34.000+00:002007-02-12T18:07:34.000+00:00Hm, am I chronically negative? I don't know.
F...Hm, am I chronically negative? I don't know.<br />Firstly, I wonder why you say that what you present is an amended version of the CICE proposal, as I cannot see any functional difference, just a different notation (you like thin arrows, don't you? ;)). Secondly, as you said yourself, CICE only provides some shortened syntax to define anonymous classes having only one method (SAM interfaces and classes), which I would call another "save me some keystrokes" proposal. Of course, it's a nice-to-have as it makes the code a bit more readable. But that's about it. Wonder if such a feature would support or rather counteract good design, as it may hype to build SAMs all over the code (like the ThreadLocal example, building abstract classes only to be able to use it as anonymous method instantiable class).<br />Of course, CICE does not have to differenciate between synchronous and asynchronous use-cases, as it only supports the restricted case anyway.<br />Why does one see closures as a feature of functional programming language only? If one has been using Smalltalk for a while, a closure is as natural an object to work with as any other, only that it contains lexically bound executable code. Inner and anonymous classes do this partially, as it is allowed to reference to the enclosing class's instance and members (and final locals).<br />Of course, BGGA has some restrictions and downsides. Some of which, I don't like, too. But it provides far more powerful features than simply simplifying anonymous object construction.Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-318988785572778722007-02-12T16:19:10.000+00:002007-02-12T16:19:10.000+00:00If the language does not evolve there is going to ...If the language does not evolve there is going to be interface duplication and general framework abuse in java for the future. For example why does Runnable exist at all? It's a function and can only be called thus (no smart encasulation here). Another example but more annoying: there is no Interface in the jdk for call(T whatever). This means that to make a "framework", that tries to hide pointless things like, the file should be accepted, etc we have the brain stress of javax.swing.filechooser.FileFilter objects. In another framework offcourse this could be anything else that did exactly the same thing and yet as the object had another name, not interchangable. Wouldn't it make more sense to give the interface that each function has by default: its arguments and return value, that is general to each and every function that accepts those arguments and returns that value?paulohttp://nourl.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-66094222308326648962007-02-12T15:06:48.000+00:002007-02-12T15:06:48.000+00:00@Evan, I like the -> but I'm not hung up on...@Evan, I like the -> but I'm not hung up on it.<br /><br />@Paulo, Not everyone agrees that functional programming is the way for Java to go. No doubt it has benefits, but it is a very different from the Java of today. If you want FP, why not use one thats designed for FP?Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16693077896477082052007-02-12T13:47:49.000+00:002007-02-12T13:47:49.000+00:00Thats pointless. The only advantage of using closu...Thats pointless. The only advantage of using closures is the possibility of creating function composition and frameworks around that. Why function composition? because functions are the primary unit computation (you can see the seen on the runnable thing that only does run()). The other principal advantage in my mind is partial evaluated functions, that unfortunately it seems no proposal is yet comtemplating. This would be immensilly usefull.<br />As an appart if java could make a NULL type for any class, that each function of that class returns a NULL type, it would remove the pointless drugery of checking for null, nullpointerexception and still allow null for function control purposes.paulohttp://nourl.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-44038148384260902212007-02-12T08:52:13.000+00:002007-02-12T08:52:13.000+00:00Something like follow?
public void init() {
exe...Something like follow?<br /><br />public void init() {<br /> executor.execute((Runnable.run()) this.processTask());<br />}<br /><br />It's a crazy idea in anyway.erkahttp://erka.kpumuk.infonoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-49670498798782589532007-02-12T07:02:19.000+00:002007-02-12T07:02:19.000+00:00very nice! but i really don't like -> notat...very nice! but i really don't like -> notation. Brings back bad memories ;) can't you use some other single character?evanxhttp://aptframework.dev.java.netnoreply@blogger.com