5 ms·

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

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 :)

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 :)