RFR: CR#8004561 : Additional Functional Interfaces and Updates

[Peter Levart]

On 12/24/2012 04:55 PM, Remi Forax wrote:
> On 12/23/2012 07:36 PM, Brian Goetz wrote:
>> Yes, this is a deliberate u-turn that comes as a result of the
>> unexpected interactions with the overloading resolution rules.
>
> maybe it's because the overloading resolution rules are not the right 
> ones ?
> I've no idea if it's better or not, I'm just thinking loudly.
>
>> By having DoubleBlock extending Block<Double>, we created problems for
>> overloading.  For example, consider this expected-to-be-common
>> overloading in Bunch<T>:
>>
>>     <U> Bunch<U> transform(Function<T,U> transformer)
>>         IntBunch transform(IntFunction<T> transformer)
>>
>> There are some conflicting rules in overload selection:
>>    - prefer more-specific SAMs to less specific (favors IntFunction)
>>    - prefer less boxing/unboxing
>>
>> What we'd like is to choose the former when the "natural" type of
>> transformer is T -> Integer and the latter when the "natural" type is T
>> -> int.  But, because the more specific rule has higher priority, we
>> would coerce a T -> Integer into a T -> int (with unboxing) all the 
>> time.
>
> Brian, Why the algorithm that select the most specific SAMs use the 
> return type of the SAM descriptor,
> the classical algorithm doesn't use the return type.
I think Brian was referring to the most specific SAM type. The 
"classical" algorithm prefers methods with more specific parameter types 
and SAM type acts as parameter type here. If IntFunction<T> is a subtype 
of Function<T, Integer> then the method with parameter of type 
IntFunction<T> is selected in preference to Function<T, Integer> 
regardless of lambda's "structural" or "natural" type, provided that 
lambda conversion is valid for both.

If parameter types of two overloaded methods are unrelated (not in a 
sub-super-type relationship) then the "classical" algorithm barfs, but 
lambda conversion can use structural properties of unrelated SAM types 
to select the most appropriate in this case.

Regards, Peter
>
> Rémi
>
>>
>>
>>
>>
>> On 12/20/2012 9:07 PM, Howard Lovatt wrote:
>>> 1. DoubleBlock doesn't extend Block<Double> and doesn't have a default
>>> method, similarly int and long
>>> 2. Similarly all the rest like Function aren't extended
>>>
>>> Is this the correct link - it seems to have gone backwards?
>>>
>>>    -- Howard.
>>>
>>>
>>> On 21 December 2012 12:41, Mike Duigou <mike.duigou at oracle.com> wrote:
>>>
>>>> Hello all;
>>>>
>>>> Here are some additional functional interfaces for review. The 
>>>> additions
>>>> fill in holes for primitive types and for two operand "Bi" operations.
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html 
>>>>
>>>>
>>>> Additionally, this patch contains naming updates on the existing
>>>> functional interfaces following 335 EG review. It does not include the
>>>> interface specializations and default methods previously proposed in
>>>> CR#8004015. That proposal has been withdrawn. It turned out that user
>>>> errors involving unexpected boxing were just too common for the value
>>>> provided.
>>>>
>>>> Mike
>>>>
>>>>
>>>
>