Function parameter order

[Remi Forax]

On 11/07/2012 05:24 PM, Brian Goetz wrote:
> Fair objection.  But I'm not hearing anyone proposing a consistent and 
> simple way to interpret the relationship between IntFoo<T> and 
> Foo<T,U>; all I'm hearing is complaining that they don't like the 
> proposed solution.

why not simply FooInt<T> ?

Rémi

>
>
> On Nov 7, 2012, at 11:14 AM, Tim Peierls wrote:
>
>> 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 
>> <mailto: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>
>>     [mailto: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
>>     <mailto: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>
>>     <mailto:kevinb at google.com <mailto:kevinb at google.com>>
>>     >>
>>     >
>>
>>
>