13 ms·

Look at what the cat dragged in - a syntax for closures in Java.

by strebler 16y ago

RodgerTheGreat 16y ago
We've been calling them "anonymous classes" for years.
- jimbokun 16y ago
  And we've been needing a usable syntax for anonymous classes for years. 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.
  - RodgerTheGreat 16y ago
    I can see that, but I'd be a lot happier if the new syntax they came up with was more consistent with the rest of the language. 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.
    - rictic 16y ago
      It is ridiculous. 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.
      - orangecat 16y ago
        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. 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.
  - deleted 16y ago
    [deleted]
    - DrJokepu 16y ago
      Compare that to how you would do it in C# (note that's not how you do comparisons specifically, this is just to demonstrate the C# lambda syntax): list.Sort((i1, i2) => i1.CompareTo(i2)); Isn't that an awful lot more readable / usable?
      - bfung 16y ago
        Yes, actually, while I was editing, I was going to mention C# delegates and new lambdas (I've been using C# 2.0, haven't upgraded yet). In my opinion, C# has been the better Java for a while; I think they should just copy C# stuff since it's already been proven to work and has some nice properties/syntax. It's not like C# didn't copy from Java in the earlier days...
    - viraptor 16y ago
      There's nothing unusable about it (by definition). But wouldn't: \(Integer i1, Integer i2) { return i1.compareTo(i2); } be nicer? (or whatever else syntax) Redundancy is already pretty common in Java and the current syntax just seems to try to win the price for most redundancy. You're implementing one interface, which you can infer in most cases with one function which you already know, which returns one result you already know the type of. So why would I want to repeat that? Sure - you can use the verbose syntax when you have many methods, but this example could be cut down to one line. Less line noise -> less errors.
  - bfung 16y ago
    Apologies: was editing, deleted, but people already replied; I always forget the markdown syntax... 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); } }); How are closures going to help?
whakojacko 16y ago
yea, that looks about right. Everyone looking for these kind of features should probably just be using Scala...
- ericlavigne 16y ago
  While I would prefer Scala over [Java + closures], and would prefer Clojure over either of those, I am still pleased to see closures in Java for several reasons. 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.
  - technomancy 16y ago
    > 2) Currently each JVM language has its own incompatible reinvention of closures. 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.
    - sreque 16y ago
      How in the world do callables replace closures? Closures can have arguments, callables can't. You cannot pass a ruby lambda expecting arguments to Clojure.
      - technomancy 16y ago
        > You cannot pass a ruby lambda expecting arguments to Clojure. I beg to differ: http://github.com/technomancy/clojure-gem/blob/master/test/test_ref.rb#L46 http://github.com/technomancy/clojure-gem/blob/master/test/t...
        16y ago
sigzero 16y ago
Maybe they are trying to make Scala the default language on the JVM with that? :-)

Look at what the cat dragged in - a syntax for closures in Java.

RodgerTheGreat 16y ago

We've been calling them "anonymous classes" for years.

jimbokun 16y ago
And we've been needing a usable syntax for anonymous classes for years. 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.
- RodgerTheGreat 16y ago
  I can see that, but I'd be a lot happier if the new syntax they came up with was more consistent with the rest of the language. 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.
  - rictic 16y ago
    It is ridiculous. 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.
    - orangecat 16y ago
      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. 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.
- deleted 16y ago
  [deleted]
  - DrJokepu 16y ago
    Compare that to how you would do it in C# (note that's not how you do comparisons specifically, this is just to demonstrate the C# lambda syntax): list.Sort((i1, i2) => i1.CompareTo(i2)); Isn't that an awful lot more readable / usable?
    - bfung 16y ago
      Yes, actually, while I was editing, I was going to mention C# delegates and new lambdas (I've been using C# 2.0, haven't upgraded yet). In my opinion, C# has been the better Java for a while; I think they should just copy C# stuff since it's already been proven to work and has some nice properties/syntax. It's not like C# didn't copy from Java in the earlier days...
  - viraptor 16y ago
    There's nothing unusable about it (by definition). But wouldn't: \(Integer i1, Integer i2) { return i1.compareTo(i2); } be nicer? (or whatever else syntax) Redundancy is already pretty common in Java and the current syntax just seems to try to win the price for most redundancy. You're implementing one interface, which you can infer in most cases with one function which you already know, which returns one result you already know the type of. So why would I want to repeat that? Sure - you can use the verbose syntax when you have many methods, but this example could be cut down to one line. Less line noise -> less errors.
- bfung 16y ago
  Apologies: was editing, deleted, but people already replied; I always forget the markdown syntax... 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); } }); How are closures going to help?

whakojacko 16y ago

yea, that looks about right. Everyone looking for these kind of features should probably just be using Scala...

ericlavigne 16y ago
While I would prefer Scala over [Java + closures], and would prefer Clojure over either of those, I am still pleased to see closures in Java for several reasons. 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.
- technomancy 16y ago
  > 2) Currently each JVM language has its own incompatible reinvention of closures. 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.
  - sreque 16y ago
    How in the world do callables replace closures? Closures can have arguments, callables can't. You cannot pass a ruby lambda expecting arguments to Clojure.
    - technomancy 16y ago
      > You cannot pass a ruby lambda expecting arguments to Clojure. I beg to differ: http://github.com/technomancy/clojure-gem/blob/master/test/test_ref.rb#L46 http://github.com/technomancy/clojure-gem/blob/master/test/t...
      - 16y ago

sigzero 16y ago

Maybe they are trying to make Scala the default language on the JVM with that? :-)