Review Request: CR#8001634 : Initial set of lambda functional interfaces
Tim Peierls
tim at peierls.net
Fri Nov 2 15:35:07 PDT 2012
Predicate, Function, Procedure works for me. Agnostic about boolean vs.
void return on Procedure.
On Fri, Nov 2, 2012 at 6:30 PM, Raab, Donald <Donald.Raab at gs.com> wrote:
> If resistance to Function is lessening, and Predicate is already decided,
> then why not just go for Procedure for forEach to round out the trio?
> These are the names we settled on in GS Collections and match the names
> Doug used in his collections framework many years ago.
>
> http://g.oswego.edu/dl/classes/collections/collections.html
>
> Most collections frameworks seem to agree on Predicate and Function. A
> couple at least have chosen Procedure that I have seen. Trove is one
> example, although their Procedure returns a boolean so it could support
> short-circuiting forEach IIRC.
>
> > -----Original Message-----
> > From: lambda-libs-spec-experts-bounces at openjdk.java.net [mailto:lambda-
> > libs-spec-experts-bounces at openjdk.java.net] On Behalf Of Brian Goetz
> > Sent: Friday, November 02, 2012 5:24 PM
> > To: Sam Pullara
> > Cc: lambda-libs-spec-experts at openjdk.java.net
> > Subject: Re: Review Request: CR#8001634 : Initial set of lambda
> > functional interfaces
> >
> > Are those really the names of what you'd want as the target for
> > forEach?
> >
> > On 11/2/2012 5:21 PM, Sam Pullara wrote:
> > > Wouldn't it be more like Runnable, UnaryRunnable and BiRunnable?
> > >
> > > Sam
> > >
> > > On Nov 2, 2012, at 1:58 PM, Brian Goetz <brian.goetz at oracle.com>
> > wrote:
> > >
> > >>> A few Googlers, myself included, have expressed surprise that Block
> > >>> accepts a value. There's nothing in the word "block" that suggests
> > >>> this to me -- no semantic basis on which to distinguish 'block'
> > from
> > >>> 'runnable'. We call this type Receiver<T>. That name has a more
> > >>> complementary nature with Supplier. Have we considered it?
> > >>
> > >> Is this surprise at the idea that a Block could accept *any*
> > arguments, or that the natural arity for Block should be zero rather
> > than one? If the latter, would UnaryBlock / BiBlock still seem weird?
> > >>
> > >> To me, Block connotes "do something via side-effects"; taking
> > arguments seems to fit well enough.
> > >>
> > >> We did consider Sink as an alternate name. Seems OK too. Anyone
> > else have opinions?
> > >>
> > >>>
> > >>> On Fri, Nov 2, 2012 at 12:32 PM, Brian Goetz
> > <brian.goetz at oracle.com
> > >>> <mailto:brian.goetz at oracle.com>> wrote:
> > >>>
> > >>> Gathering the feedback we've gotten so far:
> > >>>
> > >>> 1. Factory. People seem comfortable renaming Factory to
> > Supplier;
> > >>> as a bonus (or not), IntSupplier specializations make more
> > sense
> > >>> when connected to Supplier than Factory (how do you make new
> > >>> ints?)
> > >>>
> > >>> 2. Mapper. I agree with Doug's complaint that Mapper is too
> > >>> specialized, especially as it is probably the most useful shape
> > of
> > >>> function and will be used in places that have nothing to do
> > with
> > >>> mapping. While I've resisted "Function" for a long time (and
> > will
> > >>> continue to resist Function1..FunctionN), its not clear that
> > there
> > >>> are significantly better alternatives.
> > >>>
> > >>> 2a. IMO Fun or Func are *not* better alternatives. The extra
> > few
> > >>> characters are not an impediment, and would be inconsistent
> > with the
> > >>> other naming conventions we're adding here.
> > >>>
> > >>> 2b. The reason I've resisted Function* is that is kind of
> > gives up
> > >>> one of the few benefits of nominal function types. Structural
> > >>> function types are clearly "better", except that erased
> > structural
> > >>> function types are clearly awful. So nominal function types
> > are the
> > >>> best we can do here. Nominal function types have two
> > advantages to
> > >>> offset their many disadvantages:
> > >>> - Type names are useful and informative, especially in API
> > signatures
> > >>> - The libraries are already full of nominal function types
> > like
> > >>> Runnable and Comparator, so adding more does not create a
> > >>> bifurcation between "old libraries" and "new libraries".
> > >>>
> > >>> Going full-hog to Function1..FunctionN (for an ever-increasing
> > N)
> > >>> basically says "let's take all the disadvantages of nominal
> > types,
> > >>> and none of the advantages." API signatures that have nothing
> > but
> > >>> Function1 and Function2 in them are unlikely to be very
> > informative.
> > >>>
> > >>> Guava managed to get away with only Function and a few other
> > SAMs,
> > >>> and not need to go much further, so it is a possible candidate
> > for
> > >>> recasting Mapper, though I still don't like the slippery slope.
> > >>> Would like something better, but Mapper probably isn't it.
> > >>>
> > >>>
> > >>> So if we adopt the above we'd have:
> > >>>
> > >>> {Int,Long,Double}?Predicate: T -> boolean
> > >>> {Int,Long,Double}?Function: T -> U
> > >>> {Int,Long,Double}?Block: T -> void
> > >>> {Int,Long,Double}?__UnaryOperator: T -> T
> > >>> {Int,Long,Double}?Supplier: () -> T
> > >>> {Int,Long,Double}?{Binary,__Unary}Operator
> > >>>
> > >>>
> > >>> As to the arity modifiers (which will come in the next round),
> > it
> > >>> seems likely we'll want the equivalent of
> > >>>
> > >>> Bi{Predicate,Function,Block}
> > >>>
> > >>> Does the Bi/Tri convention scale sufficiently? Is the
> > >>> "inconsistency" (which I don't really think is an
> > inconsistency)
> > >>> with BinaryOperator excessively bothersome?
> > >>>
> > >>>
> > >>>
> > >>> On 10/31/2012 4:16 PM, Mike Duigou wrote:
> > >>>
> > >>> There's a large set of library changes that will be coming
> > with
> > >>> Lambda. We're getting near the end of the runway and
> > there's
> > >>> lots left to do so we want to start the process of getting
> > some
> > >>> of the more stable pieces put back to the JDK8
> > repositories.
> > >>> We've spent a some time slicing things into manageable
> > chunks.
> > >>> This is the first bunch. We'd like to time-box this review
> > at
> > >>> one week (until Nov. 7th), since there are many more pieces
> > to
> > >>> follow.
> > >>>
> > >>> The first chunk is the basic set of functional interface
> > types.
> > >>> While this set is not complete, it is enough to be able
> > to
> > >>> proceed on some other pieces. This set contains no
> > extension
> > >>> methods (we'll do those separately) and does not contain
> > all the
> > >>> specializations we may eventually need.
> > >>>
> > >>> 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 specification is limited; most of the interesting
> > >>> restrictions (side-effect-freedom, idempotency, stability)
> > would
> > >>> really be imposed not by the SAM itself by by how the SAM
> > is
> > >>> used in a calculation. However, some common doc for "how to
> > >>> write good SAMs" that we can stick in the package doc would
> > be
> > >>> helpful. Suggestions welcome.
> > >>>
> > >>> Elements of this naming scheme include:
> > >>> - Each SAM type has a unique (arity, method name) pair.
> > This
> > >>> allows SAMs to implement other SAMs without collision.
> > >>> - The argument lists are structured so that specializations
> > act
> > >>> on the first argument(s), so IntMapper<T> is a
> > specialization of
> > >>> Mapper<R,T>, and IntBinaryOperator is a specialization of
> > >>> BinaryOperator<T>.
> > >>> - Multi-arg versions use prefix BiXxx, TriXxx, as suggested
> > by
> > >>> Doug. However, the "natural" arity varies. No good two or
> > three
> > >>> letter prefix for zero or one comes to mind (e.g.,
> > >>> UnaryFactory<T> or NilaryBlock (though that's the same as
> > >>> Runnable.) So that could be improved.
> > >>>
> > >>> Please review and comment.
> > >>>
> > >>> http://cr.openjdk.java.net/~__mduigou/8001634/2/webrev/
> > >>> <http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> 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