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.

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




Reply via email to