Function parameter order

[Tim Peierls]

I think you'll get *huge *resistance to these arguments from actual users
to the point where it could seriously hamper adoption.

People (regular people, that is, not language jocks) more naturally say
things like "a function from X to Y", not "a function returning a Y and
taking an X". Lambdas themselves are consistent with this
inputs-then-outputs order: x -> y.

People understand things mostly by analogy. There's a preponderance of
other languages not too far removed from Java that put inputs first in
roughly analogous settings. This is not a tangential observation; it's an
important way to ensure that new users are immediately comfortable with the
lambda libraries.

Putting the return type ahead of the method name and parameters
*is*consistent with use of the method in an assignment: public Y
method(X x),
so Y y = method(x). But that's very different from Function<X, Y> and x ->
y.

[Grumpy because no power for 9 days and new storm coming.]

--tim


On Wed, Nov 7, 2012 at 10:52 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I think we're getting waaaaaaaaayyy too hung up on "I found another
> library/language that does it this way."  These things are relevant
> plus/minus considerations, but not the main consideration.
>
> Specialization (both primitive and arity) is a central part of the SAM
> naming problem -- this problem is unique to our situation, so saying
> "Library X calls it Y" is only tangentially relevant.  In any case, the
> motivation was clearly laid out in Mike's initial e-mail: we want a
> deterministic relationship between specializations of a SAM (IntFunction,
> BiFunction) and its type arguments.  Considerations related to
> specialization (such as 'this SAM name sucks when specialized', or whether
> the speicalization prefix applies to the arg type or return type) are
> important considerations that other languages haven't had to deal with.
>
> Also, note that the return-first approach is more consistent with how Java
> declares methods:
>
>   public RETURN_TYPE name(ARG_TYPE) { body }
>
> Scala declares return/arg types in the opposite order.  So "how Scala does
> thing X" is pretty much irrelevant in a vacuum when there are closely
> related things it does opposite from Java.
>
>
>
> On Nov 7, 2012, at 10:06 AM, Remi Forax wrote:
>
> > On 11/07/2012 04:02 PM, Raab, Donald wrote:
> >>
> >> +1
> >>
> >
> > +1 too,
> > it seems that scala, guava and C# uses the same convention,
> > I don't see why we should have a different one.
> >
> > Rémi
> >
> >> *From:*lambda-libs-spec-experts-bounces at openjdk.java.net [mailto:
> lambda-libs-spec-experts-bounces at openjdk.java.net] *On Behalf Of *Kevin
> Bourrillion
> >> *Sent:* Tuesday, November 06, 2012 11:59 AM
> >> *To:* lambda-libs-spec-experts at openjdk.java.net
> >> *Subject:* Function parameter order
> >>
> >> It sounds as though we're planning on Function<ReturnType, InputType>.
> >>
> >> I'd just like to note that this is going to put codebases that are in
> any stage of migration to JDK types from existing libraries including Guava
> in a really, really bad position.
> >>
> >> Every time I see Function<A, B> for /years/, I am going to have to
> check the imports to find out whether that's A->B or B-A.
> >>
> >> I'm not saying this consideration should trump all others. Just noting
> that I see this as a very bad problem for my user base.
> >>
> >> --
> >>
> >> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com<mailto:
> kevinb at google.com>
> >>
> >
>
>