RFR: CR#8004561 : Additional Functional Interfaces and Updates (original) (raw)

Peter Levart 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, we created problems for overloading. For example, consider this expected-to-be-common overloading in Bunch:

Bunch transform(Function<T,U> transformer) IntBunch transform(IntFunction 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 is a subtype of Function<T, Integer> then the method with parameter of type IntFunction 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 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

More information about the core-libs-dev mailing list