Review Request: CR#8001634 : Initial set of lambda functional interfaces

[Joe Bowbeer]

Block is OK with me, but I like Procedure better.

I don't like Source or Sink.  They sound very specialized to me.

Action is most commonly used in user interfaces, where it is associated
with a user action.  (Swing did not invent this meaning.)


On Sun, Nov 4, 2012 at 8:28 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I find Procedure (and especially its specializations) far worse than
> Block, for a number of reasons.  But many people don't like Block, so, we
> can consider some other alternatives.
>
> Action/IntAction/LongAction/DoubleAction
> plus BiAction, TriAction
>
> Not great, but OK.  Also: collsion with javax.swing.Action (not terribly
> bothersome) and the natural arity for Action is arguably zero, not one, but
> also not terribly bothersome.
>
> Rename XxxSupplier to XxxSource, and use XxxSink.  This works really
> nicely with the specializations:
>
>   IntSource, IntSInk
>   BiSink --> obviously a sink that takes two things
>
> Though some may find the primary Block-accepting method now weird:
>
>     forEach(Sink sink)
>
> and the fact that it must be side-effectful to get anything done is less
> blatant.
>
> Are either of these better thank Block?
>
> On Nov 4, 2012, at 9:06 PM, David Holmes wrote:
>
> > On 5/11/2012 3:29 AM, Sam Pullara wrote:
> >> This seems like a pretty strong existence / acceptability proof to me.
> I don't really care what they are called but I would like to close this
> thread.  Here would be my votes after listening to the points of view:
> >>
> >> Predicates
> >> Functions
> >> Procedures
> >> Operators
> >>
> >> All the methods are named apply() or get(). The length of the names
> doesn't matter as they will generally only be seen in method declarations
> where I prefer verbosity.
> >
> > Other than the plurality +1 on all counts. Proper names not
> abbreviations (like fun or proc).
> >
> > David
> >
> >> Sam
> >>
> >> On Nov 4, 2012, at 9:05 AM, "Raab, Donald"<Donald.Raab at gs.com>  wrote:
> >>
> >>>> -----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: Sunday, November 04, 2012 8:49 AM
> >>>> To: Remi Forax
> >>>> Cc: lambda-libs-spec-experts at openjdk.java.net
> >>>> Subject: Re: Review Request: CR#8001634 : Initial set of lambda
> >>>> functional interfaces
> >>>>
> >>>> For all you Procedure-lovers out there -- how do you feel about the
> >>>> specialized types
> >>>>
> >>>>  IntProcedure
> >>>>  LongProcedure
> >>>> etc?
> >>>>
> >>>> I think they're awful.  But, this naming rule serves us pretty well in
> >>>> all the other cases.
> >>>
> >>> I think they are fine.  Why do you think they are awful?
> >>>
> >>> We use them in GS Collections, and will be introducing all of the
> combinations of primitives in our next major release.  You'll notice we use
> "block" as the package to contain all of our block types including
> Predicate, Function and Procedure.  This package name was borrowed from the
> Smalltalk heritage where there was just Block and no need for anything
> else.  We've focused our energies less on the names of the types and more
> how to organize them into packages so there are not too many in a group.
>  The addition of primitive types results in a type explosion, so breaking
> them up into packages made sense to us.
> >>>
> >>>
> https://github.com/goldmansachs/gs-collections/tree/master/collections-api/src/main/java/com/gs/collections/api/block/procedure/primitive
> >>>
> https://github.com/goldmansachs/gs-collections/tree/master/collections-api/src/main/java/com/gs/collections/api/block/function/primitive
> >>>
> https://github.com/goldmansachs/gs-collections/tree/master/collections-api/src/main/java/com/gs/collections/api/block/predicate/primitive
> >>>
> >>> Five other unrelated implementations out in the wild thought using
> Procedure made sense as well.  Trove, Colt and extra166y have the primitive
> specializations, and Apache Commons Functor and the BlocksInJava author
> thought Procedure was fine at least for Object types.  The grouping in
> extra166y.Ops using a single composite interface is an interesting
> alternative to using a package structure like we are.  I haven't thought
> much on the pros/cons of the two approaches.
> >>>
> >>>
> http://trove4j.sourceforge.net/javadocs/gnu/trove/procedure/package-summary.html
> >>>
> http://acs.lbl.gov/software/colt/api/cern/colt/function/package-frame.html
> >>>
> http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/extra166y/Ops.html
> >>>
> >>>
> http://commons.apache.org/sandbox/functor/apidocs/org/apache/commons/functor/package-frame.html
> >>> http://c2.com/cgi/wiki?BlocksInJavaAst
> >>>
> >>> Apache Commons Collections chose Closure instead of Procedure like
> Apache Commons Functor.  I think Closure was a poor choice of names, for
> the same reason I think Block would be a poor choice.  It doesn't give any
> information in the name, and the implementation choice (return void) would
> probably not meet most people's expectations.
> >>>
> >>> Scala has a special syntax treatment for Procedures, although they
> don't seem to have a special type for them.  I'm guessing they use
> Function1..N to cover the type, and have Procedures just return Unit.
>  Functional Java does the same thing using F<A, Unit>  as the type for
> foreach, although they have an overloaded form of foreach which takes a
> type called Effect which returns void.
> >>>
> >>> http://www.informit.com/articles/article.aspx?p=1849236&seqNum=10
> >>>
> http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/Effect.html
> >>>
> >>> So I still vote for Predicate, Function and Procedure.  Naming things
> is really hard.  We spent a few hours on our names and said "these make
> sense to us, other frameworks look like they settled on the same names and
> people will probably just get it" and we moved on.  A lot of the time we
> spent in the discussion was on the abbreviated name alternatives as well,
> but this is because our framework is designed to work with JDK 5 - 7 and
> people have to read and write the names.  We settled on the full name
> anyway.
> >>>
> >>>
> >>
>
>