RFR: CR#8004561 : Additional Functional Interfaces and Updates
peter.levart at gmail.com
Mon Dec 24 17:17:41 UTC 2012
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
> 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.
>> 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
>>>> fill in holes for primitive types and for two operand "Bi" operations.
>>>> 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
More information about the core-libs-dev