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.dui...@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
