Function parameter order

[Brian Goetz]

> Good question.  I think reducing or at least limiting duplication should be a goal here.

I think the real goal is maximizing the usability of libraries that use 
nominal SAMs.  And by usability, I want to put the users ahead of the 
library writers.  (Consuming libraries with function types should not 
require users to even understand lambdas or functional interfaces.) 
This could argue for more duplication so the name could convey 
additional information, or argue for less duplication because having two 
different ways of doing the same thing could be confusing.  In reality I 
suspect the answers will be case-by-case, rather than one-size fits all.

Reducing the need for library writers to write their own SAMs is also a 
good goal, though I think this has to be subject to a reasonable 80/20 
rule -- shipping a thousand SAMs with the JDK does not seem realistic.


> Having two things that mean the same thing seems like a waste to me.  When you aggregate that across the 100's or 1000's of frameworks that are out there and already have their own functional types, the duplication of functional type names in Java is already tremendous.  The opportunity of interop between these types across frameworks is close to zero without an explosion of adaptation or extension methods being used everywhere.  I find it hard to understand why building duplication directly into the JDK using a nominal type that extends a low level type would be a strategy we would want to champion.  I would pick one naming strategy and go with it.  I wouldn't layer names on top of names.
>
> I agree with Doug.  Eventually you want them all, and a regularized low-level naming scheme that is easy to follow would probably lead to wider adoption outside of the JDK IMO.
>
> Here are some questions I have:
>
> Will we have an exact 1-1 mapping between nominal type and low-level type?  A yes answer would be for 100 functional types, we will have 200 interfaces defined correct?
> If we have nominal types and low-level types, when will you decide which one makes it into the method signature?
> Would we like non-JDK library developers to use the same functional types we are adding to the JDK?
> Would we like to encourage interop between libraries by having them leverage these new functional types directly, instead of by extension?
> Would we like to make the low-level functional types available to Java5-7 so libraries could adopt them before Java 8?
>
> As a library and application developer using Java, I would love to not have to own a duplicate version of these things and would rather just use what is in the JDK.  I'd like those things to be available all the way back to JDK 5 even if just as a library add-on.  If proper function types were added to Java, I would most certainly port my code bases to using the proper functional types.  With named types being added to the library, I find myself wanting to use them, but only if there is a greater opportunity for interop with other libraries.
>
> I would use a horrible consistent structural name way before a nominal name that was not designed with my library or application in mind.
>
>> -----Original Message-----
>> From: Brian Goetz [mailto:brian.goetz at oracle.com]
>> Sent: Thursday, November 08, 2012 10:47 AM
>> To: Raab, Donald [Tech]
>> Cc: Tim Peierls; lambda-libs-spec-experts at openjdk.java.net
>> Subject: Re: Function parameter order
>>
>> Let me step back and ask about your goal here.
>>
>> Doug has laid out an argument ("the tyranny of function names") that we
>> will eventually want the full combinatorial explosion, expressed in a
>> mechanizable manner.
>>
>> It is also pretty clear that any such names are going to be pretty
>> ugly, so we'd rather not make users deal with them directly if
>> avoidable.  The hope is that the two are ultimately reconcileable.
>>
>> In the review request (which, btw, we've exceeded our time box on),
>> Mike
>> stated: "Doug has also suggested we have some sort of regularized, low-
>> level naming scheme.  There's nothing in this bunch that is
>> inconsistent with that; if we had such a thing, the nominal SAMs here
>> could easily implement the horribly named low-level versions.  We're
>> still thinking about how that might fit in, so while that's not
>> directly reflected here, it hasn't been forgotten."
>>
>> The scheme you propose seems to try to play on both sides of "have some
>> nice simple names" and "have a fully regularized scheme".  What's the
>> goal here?  It is to replace all the specializations, or is it an
>> alternate casting of Doug's scheme that incorporates the
>> Predicate/Function names?
>>
>