On Dec 6 2012, at 03:59 , Chris Hegarty wrote:
> Mike,
>
> Some small comments.
>
> 1) IntUnaryOperator.java
>
> Typo in:
> + 30 * <p>This is the primitive type specialization of {@link
> IntUnaryOperator} for
> + 31 * {@code int} and also may be used as a {@code
> IntUnaryOperator<Integer>}. When
> + 32 * used as a {@code IntUnaryOperator} the default {@code operate}
> implementation
> + 33 * provided by this interface neither accepts null parameters nor does
> it return
> + 34 * null results.
>
> IntUnaryOperator -> UnaryOperator
Corrected.
>
> 2) Double/Int/Long Function
>
> "When used as a Function the default apply implementation provided
> by this interface neither accepts null parameters nor does it
> return null results."
>
> "When used as a Function", is this really necessary, or should the
> behavior of the default apply method just be described?
I agree that this is somewhat awkward. I will see if I can't think of something
better.
> Why the restriction on null parameters, it seems overly restrictive
> since applyAsXXXX accepts nulls, right?
Corrected. Thank you for noticing this.
> 3) package description
>
> "null values are accepted and returned by these functional
> interfaces according to the constraints of the specification in
> which the functional interfaces are used. The functional interfaces
> themselves do not constrain or mandate use of null values. Most
> usages of the functional interfaces will define the role, if any,
> of null for that context."
>
> Given these changes, doesn't this need to be reworked ( to indicate
> that some methods specify null value behavior)?
>
> 4) Trivially, IntSupplier is missing a '<p>', before "This is the
> primitive type..."
>
> 5) I agree with David, NPE should be defined where applicable.
I am adding these though I am still somewhat resistant for reasons I will
mention in next review cycle thread
Mike
