Bikeshed opportunity: compose vs composeWith (original) (raw)

Kevin Bourrillion kevinb at google.com
Mon Nov 26 10:21:36 PST 2012

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 Function<T,U> compose(Function<R,U> other) { ... } }

interface Comparator { // create a dictionary-order comparator default Comparator compose(Comparator 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

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