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

Brian Goetz brian.goetz at oracle.com
Mon Nov 26 12:02:00 PST 2012

Evaluating it in the context of typical usage might help:

people.sort(comparing(Person::getLast) .compose(comparing(Person::getFirst)))

people.sort(comparing(Person::getLast) .compound(comparing(Person::getFirst)))

people.sort(comparing(Person::getLast) .composeWith(comparing(Person::getFirst)))

people.sort(comparing(Person::getLast) .thenOrderBy(comparing(Person::getFirst)))

...

On 11/26/2012 2:57 PM, Kevin Bourrillion wrote:

So... comparator1.compound(comparator2)?

On Mon, Nov 26, 2012 at 11:10 AM, Brian Goetz <brian.goetz at oracle.com_ _<mailto:brian.goetz at oracle.com>> wrote: 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). It has not been suggested until now. I am fine calling this something that does not contain the string "compose". The key concept is "I have two comparators, and I want to build a dictionary-order comparator for (O1, O2)." I am fine with .compose() for functions. I think .compose(other) is too cryptic for comparators. I think .composeWith() is better; I can imagine there are other things that are also better. Now taking suggestions. (Though onResultOf does not seem better.)

-- Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com <mailto:kevinb at google.com>

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