Function parameter order

[Raab, Donald]

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