apply (original) (raw)

Doug Lea dl at cs.oswego.edu
Sun Dec 16 14:47:33 PST 2012

On 12/16/12 17:30, Remi Forax wrote:

Could someone please explain clearly and compellingly why we are using different method names for all the functional forms in java.util.function instead of just "apply"? Problems come when a functional interface inherits from another, because in that case the two methods are considered as overloads and Java has specific rules for overloads like a method with the same parameters can't have different return type. by example, if Supplier use apply, IntSupplier can not inherits from Supplier. interface Supplier { T apply(); } interface IntSupplier extends Supplier { int apply(); } // won't compile

and we want InSupplier to inherit from Supplier to avoid function interface to functional interface conversion that currently always creates a new object.

So instead live with a form that always forces you to remember to use the specially named method in the case of known-to-be-primitives?

Does anyone think that other users won't find this very annoying? It's annoying for framework writers not users of those frameworks because writing a lambda doesn't require to know the method name.

Where I guess "Framework writers" must mean:

  1. anyone using higher-order functions
  2. anyone needing to remember to for example use "operateAsDouble" vs the "operate" version in DoubleBinaryOperator to ensure lack of boxing.

-Doug

More information about the lambda-libs-spec-experts mailing list