Bikeshed opportunity: compose vs composeWith

[Brian Goetz]

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>
>