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

[David Holmes]

Hi Mike,

A few small comments:

BinaryOperator:

Typo: the the

---

Block:

* @param t an input object

-> the input object

---

typeBinaryOperator

* Combines two {@code type} operands of the same type

As opposed to two type operands of different type? :)

typeMapper explicitly says it is the type specialization of Mapper, but 
typeBinaryOperator doesn't say the same thing about BinaryOperator. 
Ditto for UnaryOperator. We need a consistent approach here.

---

DoubleUnaryOperator
IntUnaryOperator:

  @param operand The operand value.

The -> the

General consistency note: sometimes the @param descriptive text starts 
with a capital and sometimes not.

----

Mapper:

"A mapper may variously provide a mapping between types, object 
instances or keys and values or any other form of transformation upon 
the input."

I can't parse this sentence and I'm not sure it is adding value beyond 
what is already said in the first sentence.

---

UnaryOperator:

  * @param <T> the type of input objects to {@code operate} and of the 
result.

objects -> object

and perhaps "the type of ^the^ input object ..."

---

package-info.java

* <em>Functional interfaces</em> provide typing for lambda methods.

lambda methods? Do you mean lambda expressions?

"non-defaulted" is a horrible term. Isn't it simply abstract? Seems to 
me that "abstract default" should not be permitted and that default 
wipes out any implicit abstract. That way a default method is not an 
abstract method, while an abstract method is what it always has been: a 
method signature with no implementation.

+ * <p>All functional interface implementations are expected to:

The above lead in does not read correctly with the subsequent bullet points

Cheers,
David

On 1/11/2012 6:16 AM, 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, 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.
>
> 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>.
>
> In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review:
>
> - We are time-boxed at one week. (until Nov. 7th)
>
> - Please review the whole bunch in a single message if possible, rather than in bits and pieces.  It is far easier to extract useful feedback from one complete review than from a dozen partial ones.
>
> - Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content.  It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on.
>
> http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/