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

[Joe Bowbeer]

I like Function::apply

Here are alternatives for Procedure

Procedure::do
Procedure::perform


On Sat, Nov 3, 2012 at 11:19 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 11/03/2012 07:03 PM, Joe Bowbeer wrote:
>
>> By the way, don't the method names matter?  If so, shouldn't naming
>> proposals include the corresponding method names?
>>
>
> yes, it's a good idea.
>
>
>
>> I assume the following are correct:
>>
>> Operator::operate
>> Predicate::test
>> Procedure::apply
>>
>
> Procedure::proceed
>
>
>  Supplier::supply
>>
>> But what does a Function do?  (What method corresponds to Function?)
>>
>> Function::fun ?
>>
>
> Function::apply
>
>
>> --Joe
>>
>
> Rémi
>
>
>> On Sat, Nov 3, 2012 at 10:39 AM, Joe Bowbeer wrote:
>>
>>     Comments on Brian's update and later comments related to it:
>>
>>     1. I like Supplier (or Locator?) better than Factory.  Both are
>>     compatible with reuse.
>>
>>     But what is the method called?  Doesn't 'make' have the same
>>     problem as Factory?  If the method remains 'make' then why not
>>     call the class "Maker"?
>>
>>     2. I'm OK with Function, Predicate, Procedure
>>
>>     Procedure must have void return
>>
>>
>>
>>     On Fri, Nov 2, 2012 at 12:32 PM, Brian Goetz 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/>
>>             <http://cr.openjdk.java.net/%**7Emduigou/8001634/2/webrev/<http://cr.openjdk.java.net/%7Emduigou/8001634/2/webrev/>
>> >
>>
>>
>>
>>
>