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

Remi Forax forax at univ-mlv.fr
Mon Nov 26 14:37:57 PST 2012

On 11/26/2012 09:06 PM, Brian Goetz wrote:

I like the "then" convention to indicate sequencing. In context:

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

or people.sort(comparing(Person::getLast, Person::getFirst)) (comparing is a static method so it can be annotated with @SafeVarargs).

Rémi

On 11/26/2012 3:04 PM, Sam Pullara wrote: How about something that sounds more comparator specific: comparator1.thenCompare(comparator2) Sam On Nov 26, 2012, at 11:57 AM, Kevin Bourrillion <kevinb at google.com_ _<mailto:kevinb at google.com>> 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