Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces

[Louis Tribble]

At a practical level, the "all different" strategy plays better with IDE search and refactoring implementations when code bases get large. For some of us, that's a quality of (work) life issue :)

Louis Tribble

On Nov 13, 2012, at 3:34 PM, Brian Goetz wrote:

> Right.  There are basically two consistent choices here:
> - All SAM methods have the same method name
> - (Basically) all SAM methods have different method names.
> 
> The arguments in favor of "all same" are:
> - Having them all be the same means you always know it
> 
> The arguments in favor of "all different" are:
> - The name may convey additional meaning in client code
> - Greatly reduced chance of problems when one SAM extends another, or when a class implements multiple SAMs using default methods
> 
> 
> For example, a collision could come up if we wanted (which I think we do)
> 
> IntFunction<T> extends Function<T,Integer>
> 
> in which case we would be trying to overload
> 
>  int apply(T)
> and
>  Integer apply(T)
> 
> Even if we didn't have any cases where these collisions would be problematic today, choosing "all same" means that if we find them later, we're screwed.  Given that the "all different" strategy is so easy, it seems foolish to reach for "all same."  (The "cognitive load" argument in favor of "all same" is reduced by (a) IDEs will help and (b) lambda uses do not need to know the name.  Further, the "all different" approach feels more in the spirit of nominal function types, to which we've committed, however uncomfortably.)
> 
> So, I basically don't see "all same" as a smart choice.
> 
> On 11/13/2012 6:26 PM, Joe Bowbeer wrote:
>> Hey Brian,
>> 
>> Judging from Mike's email, I gather that these "apply" method names do
>> need to be unique?
>> 
>> Just hoping you can clarify...
>> 
>> 
>> On Tue, Nov 13, 2012 at 12:14 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com>> wrote:
>> 
>>        I've updated the webrev for the first set of lambda functional
>>        interfaces (JSR-335) with the feedback from the first review
>>        round. The updated webrev is:
>> 
>>        http://cr.openjdk.java.net/~__mduigou/8001634/3/webrev/
>>        <http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/>
>> 
>>        This update includes:
>> 
>>        - Mapper.map becomes Function.apply
>>        - Factory.make becomes Supplier.get
>>        - Specializations of Supplier for int, long, double
>>        - Reorder type variables to put result last
>>        - Fixes many javadoc and stylistic comments.
>> 
>>        What didn't change:
>>        - Block was not renamed to Action or Procedure. The name
>>        Block.apply currently conflicts with Function.apply and should
>>        be renamed. Block.accept? Block.perform?
>> 
>> 
>>    Block.accept.
>> 
>>    Also, to allow IntFunction<T> to implement Function<T,Integer>, need
>>    to adjust the method names.  Propose
>> 
>>       applyAs{Int,Long,Double}
>> 
>>    for specializations.
>> 
>>    Similarly, need to do the same for Supplier:
>> 
>>       getAs{Int,Long,Double}
>> 
>>    with appropriate defaults for the specialized versions.
>> 
>>