@FunctionalInterface implications

[Remi Forax]

On 11/23/2013 02:32 AM, Brian Goetz wrote:
> Function is extended by BinaryOperator, also a functional interface,
> which specializes its type parameters.  I think that's a fine pattern.

Brian,
I don't want to restart the thread about the naming of UnaryOperator and 
BinaryOperator,
but  BinaryOperator is a BiFunction not a Function, UnaryOperator is a 
Function.

BTW I've recently discover something weird, Function.identity() should 
return a UnaryOperator<T> and not a Function<T,T> which can be seen as 
an hint of the fact that having two interfaces for something so similar 
is not a good idea.

I think we have missed a point when we have discussed about naming, the 
real question is why UnaryOperator and BinaryOperator exist, from now, 
they does not seem to worth their weight (naming, specialization, etc) ?

Rémi

>
> More generally, its perfectly fine for an interface to extend a
> functional interface but not itself be a functional interface.  See
> Node.Builder inside the Stream package, for example.
>
> On 11/22/2013 7:50 PM, Richard Warburton wrote:
>> Hi,
>>
>> If the intent of an interface marked with @FunctionalInterface is to be
>> used as such then should it ever be extended by another interface?
>>
>> I appreciate there are probably enough complex interactions that generating
>> a compile error if this happens would be too restrictive but what about
>> 'morally' or as a guideline?
>>
>> regards,
>>
>>     Richard Warburton
>>
>>     http://insightfullogic.com
>>     @RichardWarburto <http://twitter.com/richardwarburto>
>>