Look at what the cat dragged in - a syntax for closures in Java.
I am fully onboard with closures as semantically equivalent to an anonymous class with a single method. The current syntax for creating them, though, is ridiculous.
I don't think the current syntax for anonymous classes is 'ridiculous', it's just inconveniently verbose when you only want a single method. If you're implementing a more complex interface, the current method is actually pretty good.
Java often completely ignores the design guideline of making the easy things easy and the hard things possible, preferring just to make the hard things possible. Anonymous inner classes with many methods are far less commonly needed than anonymous functions, and it's rare that the program is better served having them inline rather than defined elsewhere anyways.
Five lines and dozens of characters of boilerplate for every anonymous function does come at a cost and is ridiculous.
That's it exactly. My "favorite" example is file I/O. Yes, it's great that I can chain a bunch of InputStream instances together to read encrypted gzipped serialized objects over the network, but it shouldn't be more than one line for the far more common case of reading a file's contents into a string or a byte array.
Just to play devil's advocate, what is unusable about the syntax for anonymous classes in Java? An example close to bnoordhuis's post below, in today's syntax:
Collections.sort(list, new Comparator<Integer>() {
public int compare(Integer i1, Integer i2) {
return i1.compareTo(i2);
}
});
Everyone looking for these kind of features should probably just be using Scala...
1) For now, I still have a job as a Java programmer. Closures in Java will save me some lines of code until I can fix that.
2) Currently each JVM language has its own incompatible reinvention of closures. I think that closures in Java are a step towards better interoperability between JVM languages.
3) A lot of programmers will be introduced to a higher level of abstraction than they otherwise would have.
http://freegeek.in/blog/2010/05/clojure-protocols-datatypes-...
Yeah, but as long as they expect Callables in the right place interop can be pretty easy with just interfaces. For instance, you can pass JRuby lambdas to Clojure functions just fine. Sure there's a duplication of effort, but it's not too bad for interop purposes.
I beg to differ: http://github.com/technomancy/clojure-gem/blob/master/test/t...
Again, you cannot pass a ruby function expecting arguments to Clojure! What your link shows is that you can, however, send monkey-patched versions of ruby functions that implement clojure-specific calling conventions to clojure. :)
http://news.ycombinator.com/item?id=1257599
Good point regarding the effect on interoperability. I don't have an answer for that.