Code review request

[Paul Sandoz]

Hi Tim,

Thanks for the comments.

On Feb 23, 2013, at 6:06 PM, Tim Peierls <tim at peierls.net> wrote:

> On Thu, Feb 21, 2013 at 2:17 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> At
>>  http://cr.openjdk.java.net/~**briangoetz/jdk-8008670/webrev/<http://cr.openjdk.java.net/~briangoetz/jdk-8008670/webrev/>
>> 
>> I've posted a webrev for about half the classes in java.util.stream. None
>> of these are public classes, so there are no public API issues here, but
>> plenty of internal API issues, naming issues (ooh, a bikeshed), and code
>> quality issues.
>> 
> 
> Things I noticed before I ran out of steam:
> 
> In AbstractTask<P_IN, P_OUT, R, T> the use of multicharacter type
> parameters is confusing, especially with an underscore. AbstractTask<S, T,
> R, C>, <T, U, R, C>, or even <K, V, R, T> would be better.
> 

I added "P_IN" etc because i found i kept forgetting which single character type variable corresponded to what :-)

So for the following:

interface IntermediateOp<E_IN, E_OUT> {
    Sink<E_IN> wrapSink(int flags, Sink<E_OUT> sink);
    default <P_IN> Node<E_OUT> evaluateParallel(PipelineHelper<P_IN, E_OUT> helper)

I found it clearer which variables were corresponding to the input/output types of of pipeline and which to the ops, and have attempted to stick to that pattern throughout the code, although i suspect it is not completely consistent. Having said that i think consistency is of use is the most important aspect.


> BiBlock -> BiConsumer in Map.java comments.
> 

Fixed in the lambda repo.

Paul.