Function parameter order (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed Nov 7 15:14:39 PST 2012

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 RETURNTYPE name(ARGTYPE) { 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>

More information about the lambda-libs-spec-observers mailing list