apply

[Howard Lovatt]

I don't think different names, e.g. for Function's and IntFunction's method name, it is a big deal if you use an IDE, it prompts. Also the code can read better, for example Predicate's method name can be test which reads better than apply. 

Sent from my iPad

On 17/12/2012, at 9:47 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> 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> { 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
> 
>