4 ms·

On the consumption side, yes. As far as I can tell, you still need to write out the function interfaces :(

cromwellian 13y ago
But that's exactly the way library APIs should work, with all the pain and labor going into the API declaration, and the users of the library experiencing very little. In type inferenced statically typed languages like ML, Scala, or Haskell, you can get away with not mentioning the types in the bodies of most functions. The type declarations at the library level serve as useful documentation.
- ajanuary 13y ago
  That creates a somewhat artificial boundary between libraries and consumers. I write plenty of code at all layers that would benefit from being able to accept code as an argument. If I want a private helper method that takes some code as an argument, do I have to create and name a function interface just for that? Yes, Javascript's anonymous function syntax is needlessly verbose, but that's trivially fixed and will be in future versions. Changing Java to not need a function interface is a much bigger challenge that I'm willing to bet won't come about for a long time, and is going to be a source of frustration for lots of people as they realise how useful cheap anonymous functions can be.
  - cromwellian 13y ago
    I'd argue that there already is, in well written libraries, an artificial boundary. Library APIs often have to be written for the consumption of others, so more care is usually given (in well written) libraries. You don't really need to create any function interfaces for most expressions since the most common ones are pre-defined (Supplier, Consumer, Predicate, Function, UnaryOp, BinaryOp, etc), and the basic rules allow a lot of flexibility. I've been doing a lot of Java8 recently due to work integrating it into GWT (https://plus.google.com/+RayCromwell/posts/C4QYmWWQguT https://plus.google.com/+RayCromwell/posts/C4QYmWWQguT) and the experience has been delightful. In actual use (as opposed to testcases), it's been very economical, especially the this::foo constructor vs the JS equivalent which needs bind(), and the fact that you get good auto-complete is great.
    - ajanuary 13y ago
      My comment was poorly phrased regarding libraries. What I meant was there's plenty of code if want to use lambdas for that isn't a carefully planned api boundary. Even with the provided function interfaces I worry there will be cases they don't cover which means people won't use anonymous functions where they're useful. However, given you seem to have used Java 8 and. I haven't, I'll relent :)

But that's exactly the way library APIs should work, with all the pain and labor going into the API declaration, and the users of the library experiencing very little. In type inferenced statically typed languages like ML, Scala, or Haskell, you can get away with not mentioning the types in the bodies of most functions. The type declarations at the library level serve as useful documentation.

ajanuary 13y ago
That creates a somewhat artificial boundary between libraries and consumers. I write plenty of code at all layers that would benefit from being able to accept code as an argument. If I want a private helper method that takes some code as an argument, do I have to create and name a function interface just for that? Yes, Javascript's anonymous function syntax is needlessly verbose, but that's trivially fixed and will be in future versions. Changing Java to not need a function interface is a much bigger challenge that I'm willing to bet won't come about for a long time, and is going to be a source of frustration for lots of people as they realise how useful cheap anonymous functions can be.
- cromwellian 13y ago
  I'd argue that there already is, in well written libraries, an artificial boundary. Library APIs often have to be written for the consumption of others, so more care is usually given (in well written) libraries. You don't really need to create any function interfaces for most expressions since the most common ones are pre-defined (Supplier, Consumer, Predicate, Function, UnaryOp, BinaryOp, etc), and the basic rules allow a lot of flexibility. I've been doing a lot of Java8 recently due to work integrating it into GWT (https://plus.google.com/+RayCromwell/posts/C4QYmWWQguT https://plus.google.com/+RayCromwell/posts/C4QYmWWQguT) and the experience has been delightful. In actual use (as opposed to testcases), it's been very economical, especially the this::foo constructor vs the JS equivalent which needs bind(), and the fact that you get good auto-complete is great.
  - ajanuary 13y ago
    My comment was poorly phrased regarding libraries. What I meant was there's plenty of code if want to use lambdas for that isn't a carefully planned api boundary. Even with the provided function interfaces I worry there will be cases they don't cover which means people won't use anonymous functions where they're useful. However, given you seem to have used Java 8 and. I haven't, I'll relent :)