Function parameter order

[Remi Forax]

On 11/07/2012 11:33 PM, David Holmes wrote:
> 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
> -----

+1

Rémi

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