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

Brian Goetz brian.goetz at oracle.com
Tue Nov 13 15:34:45 PST 2012

Right. There are basically two consistent choices here:

The arguments in favor of "all same" are:

The arguments in favor of "all different" are:

For example, a collision could come up if we wanted (which I think we do)

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

More information about the lambda-libs-spec-observers mailing list