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

[Raab, Donald]

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