Function parameter order

[David Holmes]

On 8/11/2012 1:52 AM, Brian Goetz 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.

I think you've made the tail wag the dog here. You prefer IntMapper et 
al to MapperInt, and you want prefix to indicate first type parameter, 
therefore Return type must come first.

But expressing Return type first is not the common definition for 
functions/mappings

A function f from A to B denoted f:A->B is a relation from A to B such 
that for all a in Dom(f), f(a) contains just one element of B.

(That's from my first year Discrete Maths for Computer Science Uni 
textbook).

So existing precedents and conventions say Return type comes last, so 
that implies a suffix and hence MapperInt - if you want to maintain your 
naming scheme.

I don't particularly like MapperInt either but I'll put up with it to 
keep the type arguments in the expected order. (Though MapperToInt is 
undoubtedly better still).

These specializations are a workaround for a lack of decent primitive 
type support, so their naming should not be the major decision criteria 
when designing the API.

David
-----


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