Review request for initial lambda functions and utils

[Stephen Colebourne]

Some thoughts.

- I don't like using the term "map", or even "mapper" because of the
prior meaning of Map (ie. a hash map) in Java. I would prefer to see
Transformer.

- I would prefer to see all Javadoc specify whether a parameter/return
can take or return null. eg:
     * @param second an additional Block which will be chained after
this Block, may be null
     * @return a Block which performs in sequence the {@code apply} method of
     * this Block and the {@code apply} method of the specified Block
operation, not null

- I'm glad to see both vararg and iterable versions of the methods are
being thought of. I do think a language change to unite arrays,
varargs and iterables would be better however.

- The public static constants look wrong here, athough they could be
staticly imported.

- It feels unnatural to have the code in a different file to the
interface given that they seem linked.

- Formatting of the lambdas is pretty horrible for readability. There
seems to be an attempt to "bung everything on one line" in many cases,
even though this is the opposite of idiomatic Java and good style in
the wider Java industry. Thus:

 return #{ T t -> first.apply(t);for(B block : blocks) block.apply(t); };

should be

 return #{ T t ->
   first.apply(t);
   for (B block : blocks) {
     block.apply(t);
   }
 };

Note that this point leads to the syntax discussion (because -> at the
end of the line is just crazy). I *hope* that part of the point of
these sample APIs is to push at what the style of lambda writing will
be. My conviction is that the style used in Blocks (first example
above) and elsewhere is far too compact for Java where developers
actually prefer a little more verbosity than in some other languages,
because they understand the trade off of readability vs maintenance.

Most Blocks methods and Blocks.repeatUntil and Blocks.chain varargs in
particular are too complex for a single line.
Mappers.cloneOf has a lambda block that doesn't end when you think it does
Mapper.forMap 1 arg has braces that are all over the place.
Predicates.and (and others) tries to be clever with the lambda closing
brace and it looks stupid.

For example, it is my strong opinion that seeing ); }; at the end of a
line is not good style at all.

I should also note that glancing over
 return #{U base, V v -> reducer.reduce(base, mapper.map(v)) };
I saw V v -> reducer.reduce(base, mapper.map(v)) };
I had to really go bad and mentally force myself to try to connect "U
base" to ->

Stephen



On 9 August 2011 04:02, Mike Duigou <mike.duigou at oracle.com> wrote:
> Late last week I committed an initial version of the proposed standard basic lambda functions and some utils for those functions to the OpenJDK lambda repository. The implementation (especially the oh-so-tedious-javadoc and unit tests) is still very rough but we are interested in hearing feedback. For now focus your feedback on:
>
> - approach
>    - Is there a different way to solve the problem?
> - completeness
>    - What *must* be there that is missing?
> - stylistic/usage issues
>    - Copying inputs vs to not copy inputs--see Predicates.contains() vs. Predicates.or(Predicate<T>... )
> - surprising behaviour
>    - self-inconsistency or surprising behaviour with respect to other Java APIs.
> - usage problems
>    - I can't use this to X
>
> This API will see incremental progress in the next couple of weeks. Over time other useful bits such as extension methods for Collection, List, Set utilizing lambda functions will also appear.
>
> Mike
>
>