Code review request

Paul Sandoz paul.sandoz at
Tue Feb 26 03:03:00 PST 2013

Hi Tim,

Thanks for the comments.

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

> On Thu, Feb 21, 2013 at 2:17 PM, Brian Goetz <brian.goetz at> wrote:
>> At
>> I've posted a webrev for about half the classes in 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 comments.

Fixed in the lambda repo.


More information about the lambda-libs-spec-observers mailing list