RFR: CR#8004561 : Additional Functional Interfaces and Updates

[Howard Lovatt]

The disadvantage of IntFunction<T> not extending Function<T, Integer> is that you can no longer provide a function that handles int and Integer and this requirement is also common in my experience. The method I have handled this in my own library is to use a naming convention of prefixing the primitive versions with the type. Therefore I would write Bunch etc. as:

interface Function<I, O> { O call(I i); }
interface IntFunction<I> extends Function<I, Integer> {
  default Integer call(I i) { return intCall(i); }
  int intCall(I i);
}
DoubleFunction etc. 
interface Bunch<I> { <O> Bunch<O> transform(Function<I, O> t); }
interface IntBunch<I> extends Bunch<I> {
  default Bunch<Integer> transform(Function<I, Integer> t) { return intTransform(t); }
  IntBunch intTransform(IntFunction<I> t);
}
DoubleBunch etc. 

The ambiguity goes away because of the naming convention and type hierarchy. 

  -- Howard. 

Sent from my iPad

On 25/12/2012, at 4:17 AM, Peter Levart <peter.levart at gmail.com> wrote:

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