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/
