Bikeshed opportunity: compose vs composeWith

[Kevin Bourrillion]

I'm not sure "A compose with B" really does have any less ambiguity than "A
compose B."  I would lean toward sticking with compose.

However, this is the first time I'm noticing that you're using the name
compose() not only for function composition, but also for forming a
compound comparator.  Has it been suggested that we not reuse the compose()
name to mean this other thing?  Note that there does exist a compose
operation for Comparators, but it's (Function, Comparator) -> Comparator
(Guava puts it in the other order and calls it "onResultOf", which I'm not
recommending).



On Mon, Nov 26, 2012 at 10:01 AM, Brian Goetz <brian.goetz at oracle.com>wrote:

> We've got two changesets in flight that introduce a compose method:
>
> interface Function<T,R> {
>     default<U> Function<T,U> compose(Function<R,U> other) { ... }
> }
>
>
> interface Comparator<T> {
>     // create a dictionary-order comparator
>     default Comparator<T> compose(Comparator<T> other) { ... }
> }
>
>
> We received some feedback that users found "compose()" at the use-site
> slightly ambiguous.  I'm starting to lean towards "composeWith(fn)",
> despite it being slightly more wordy.  Preferences?
>
>   Comparator byFirst = Comparators.comparing(Person::**getFirstName);
>   Comparator byLast = Comparators.comparing(Person::**getLastName);
>   Comparator byFirstLast = byLast.composeWith(byFirst);
>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com