Function parameter order

[Brian Goetz]

That's my thought too.  The point of narrowing the list to the current 
review set was to put out the core (hopefully noncontroversial) types 
and then add in whichever additional ones are needed for 
80%-completeness later in this round (e.g., arity specializations, 
reducers.)



On 11/8/2012 12:04 PM, Raab, Donald wrote:
> I think you cover the 80% with less than 50.
>
>> -----Original Message-----
>> From: Brian Goetz [mailto:brian.goetz at oracle.com]
>> Sent: Thursday, November 08, 2012 11:52 AM
>> To: Raab, Donald [Tech]
>> Cc: Tim Peierls; lambda-libs-spec-experts at openjdk.java.net
>> Subject: Re: Function parameter order
>>
>>> 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?
>>>>
>>>