RFR: CR#8004561 : Additional Functional Interfaces and Updates
forax at univ-mlv.fr
Mon Dec 24 15:55:05 UTC 2012
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.
> 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.
>>> 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