Function parameter order

[Brian Goetz]

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