Comparator

[John Rose]

On Jul 24, 2013, at 7:43 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> yes, that what John said.

The basic idea (or fond hope) is that the name resolution and type-inference machinery that deals with a static call X.m(a,b) could also be harnessed to deal with a non-static call x.m(a,b), viewed as X.m(x;a,b) with extra TVs on the x; parameter.  I assume that the (raw) class of x (like X) can first be determined, without solving all TIVs in x.  Then users won't have to write statics X.m(x,a,b) in order to get inference on x.

> And this is important because otherwise people will start using static 
> methods instead of instance methods,
> in fact it's already an issue:

The reason I'm wildly waving this flag is that (I think) I have seen this phenomenon active during the design of streams APIs, ongoing now.

Possible example:
  aStream.collect(Collectors.groupingBy(clsfr, dnstrm))

Maybe that's the best form, but I think this nice option wasn't even on the table:
  aStream.collect(dnstrm.groupingBy(clsfr))

You can find more examples like this by grepping for "static", looking for static methods which could be viewed as transforming (fluently) one of their arguments, and then considering use cases.

— John

P.S.  Somebody mentioned method paths, which if taken seriously would create "path constraints" for TIVs and inject structural typing everywhere. I think that is recognizable as a bad road to take.