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

[Brian Goetz]

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