Self-type

[John Rose]

On Jun 17, 2015, at 2:11 AM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:

> It seems to me that the receiver type being treated as a special case from the types of the other parameters is an unnecessary inconsistency.

I get what you are saying here, though I would say more carefully "some special rules for the receiver argument are unnecessarily different from the rules for other arguments".  Receivers will always be a little different from other arguments, because dynamic method selection introduces type shifting when an overloading is invoked, but those differences could be more carefully localized, in the Java of some parallel universe.  I would prefer we were in a world where the difference between "a.m(b)" and "m(a,b)" is little more than surface syntax, to be tweaked by tasteful library designers.

Here's my pet peeve in this vein:  Type inference rules treat receiver types as less coupled to constraints than other types; this is why some design patterns can only be written using Java statics, and not using instance methods—which (as you note here) is a pain, since the language syntax clearly favors non-static methods (for fluent APIs, as you refer to).  This irregularity weakens type inference in fluent builder expressions, when the thing being built has type variables.

But.  Pointing out the inconsistency is not even remotely close to deciding on a fix.  Making receiver types work consistently like other types would almost certainly require deep and destabilizing changes to the JLS.  Figuring out all the required changes and their impacts (on zillions of lines of code) is a long-term research project, somewhere (IMO) in complexity between inner classes and generics.

(Volunteers?)

— John