Bikeshed opportunity: compose vs composeWith

[Raab, Donald]

(Resending with tail cut a bit as it got blocked... sorry if you get this twice)

No problem.  Yes, “by” here would take Function.  Looks like your variable naming is pretty much like our naming, which is an obvious choice for variable names in this case IMO.  I would be fine with thenComparing taking Comparator.

people.sort(by(Person::getAge))
people.sortBy(Person::getAge)

people.min(by(Person::getAge))
people.minBy(Person::getAge)

people.max(by(Person::getAge))
people.maxBy(Person::getAge)

Going with “by” as the api on Comparators for Function makes implementing the second api shortcut above a lot less attractive.  It saves very little, and costs a lot.

If we can get agreement on the name, I’d love to then jump in the discussion about Serializability of chained/composed Comparators/Functions.  I might be missing something obvious, but without extending Serializable on Comparator and Function, there is going to have to be some interesting instanceof checking inside by/comparing/thenBy/thenComparing/reverse/etc.  

How would we make this Serializable?

TreeSet<Person> peopleByLastNameFirstNameAndAgeDesc = new TreeSet(by(Person::getLast).thenBy(Person::getFirst).thenComparing(by(Person::getAge).reverse()));

I’m sure some folks will want to say “Edge case! Foul! No one uses serialization!”.  That’s of course is the easy way out.  ;-)  But maybe there is actually an easy way out I haven’t thought of or am not aware of because of some discussion thread I may have unfortunately missed.


From: Kevin Bourrillion [mailto:kevinb at google.com] 
Sent: Thursday, November 29, 2012 2:45 AM
To: Raab, Donald [Tech]
Cc: Brian Goetz; Sam Pullara; lambda-libs-spec-experts at openjdk.java.net
Subject: Re: Bikeshed opportunity: compose vs composeWith

As soon as I hit send I realized I was thinking of the *by() methods as taking Comparators as their parameters, which is wrong.  Perhaps responding on this thread at 2:45 am was a suboptimal idea. Sorry!


On Thu, Nov 29, 2012 at 2:43 AM, Kevin Bourrillion <kevinb at google.com> wrote:
Note that a very natural way that users are naming their comparator instances is to start with "by" :  Comparator<User> byIdDesc, or Comparator<Account> BY_BALANCE, etc. I know that this is "common" in Google code (I could get more specific if necessary).

These, of course, would become dreadful names overnight if the method names we use themselves end in "by".

That's just one more small reason why my preference is still for comparing/thenComparing.