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

[Brian Goetz]

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