implicit 'return this' JCP suggestion

[Brian Goetz]

This is well-traveled ground.

Clearly you could write your setter to return its receiver with today's 
language.  In reality, the elision of 'return this' is a pretty small 
benefit; in reality, the ihe implicit goal of your proposal is to make 
the transition from void-return to self-return for _existing libraries_ 
a _binary-compatible_ change, by having self-return be handled on the 
client side (permission to reuse the receiver).

But this still has a deficit, which is that libraries must explicitly 
perform the migration from void-return to self-return, and many will 
not, either because they have other priorities, or because they don't 
want to tie themselves to the Java 18+ classfile version (limiting the 
applicability of their library.)  This means that it will be the better 
part of a decade before most libraries have migrated, with the result 
that an inconsistent mix of libraries will support it, to the 
frustration of users.

An alternate approach that has been floated is to simply permit 
client-side receiver chaining on void-return methods:

    foo.setX(3).setY(4)

by simply reusing the receiver when chaining void methods.

But still, this has a deficit; the real payoff for such a feature would 
be that one could create, set up, and return an object _in a single 
expression_.  The above only gets us halfway there; instead of:

    Foo f = new Foo();
    f.setX(3);
    f.setY(4);
    use(f);

we can do:

    Foo f = new Foo();
    f.setX(3).setY(4);
    use(f);

But this only eliminates the lesser of the annoyances; the biggie is 
that we cannot create the Foo and initialize it in one go:

     use(new Foo().setX(3).setY(4).WHAT_GOES_HERE())

To get there, we'd have to further interpret x.m(), where m() is a void 
method, as evaluating to x:

     use(new Foo().setX(3).setY(4))

which is now a more invasive change (and conflicts with the desire to 
make `void` an actual type under Project Valhalla.)

Further, under such a scheme, it is likely that existing API decisions 
will give users grief.  For example, Collection::add is not a void 
method, it returns a boolean indicating whether a change was made or 
not.  So users will surely try:

     new ArrayList<>().add(3).add(4)

and be surprised it doesn't work.  (Moral: mid-game rule changes are 
always more disruptive than you think.)

In summary, while the goal of this proposal is well-intentioned, and 
parts of the proposed solution are workable, when you work through the 
details, you end up somewhere that is more invasive than expected, for a 
relatively small benefit.


On 7/21/2021 7:22 PM, Scott Morgan wrote:
> Hi All,
>
>    I have a JCP suggestion (between my first and 2nd signatures below), and
> I am wondering if anyone on this list can submit it on my behalf, or if
> they are interested in collaboration on it.
>
> Cheers and TIA!,
> Scott
>
> Summary
>
> -------
>
>
>
>    Implicit return of this;
>
>
>
>    Provide better syntactic sugar for method chaining in Java, through
> allowing the 'this' keyword to be used
>
> in the return class slot of Java methods.  In addition methods marked as
> returning 'this' would implicitly return
>
> this with out the explicit 'return this;' statement at the end of the
> method.  For example;
>
>
>
> public interface MyInterface {
>
>    this setFoo(String foo);
>
> }
>
>
>
> public class MyClass implements MyInterface {
>
>    private String foo;
>
>
>
>    public this setFoo(String foo) {
>
>      this.foo = foo;
>
>      //note the implicit return this;
>
>    }
>
> }
>
>
>
> public class MyChildClass extends MyClass  {
>
> // NO NEED FOR THIS METHOD NOW YEA, it now returns MyChildClass!
>
> //  public MyChildClass setFoo(String foo) {
>
> //    super.setFoo(foo);
>
> //    return this;
>
> //  }
>
> }
>
>
>
> Goals
>
> -----
>
>    The primary goal is to make Java easier to use, less typing required and
> improved readability.
>
> Removal of repetitive code.
>
>
>
> Non-Goals
>
> ---------
>
>
>
>    This is not designed to promote method chaining, as that is subjective.
> However for the developers
>
> who like method chaining, it should improve their experience with Java.
>
>
>
> Success Metrics
>
> ---------------
>
>
>
>    Take a vote of JCP members to see if they think this is a good idea, for
>
> developer productivity with the language.
>
>
>
> Motivation
>
> ----------
>
>
>
>    I have been spending a lot of time overriding methods in child classes in
> order to
>
> make all of the methods return the same type.  This creates a lot of nearly
> identical
>
> code, violating the DRY principles (don't repeat yourself).  The only
> difference is the
>
> return type in the leaf most class of the class parent child tree.
>
>
>
> Description
>
> -----------
>
>
>
> I'm hoping someone else will implement this JEP.  However I think
>
> it would be fairly straight forward step in the java compilers.
>
> When the compiler encounters a 'this' in the return type slot
>
> it would return the current class.  For all subclasses and
>
> implementations the compiler would have bytecode generated that would
>
> call the super method and then return this.
>
>
>
> Alternatives
>
> ------------
>
>
>
> I haven't considered any alternatives.  The current work around is pretty
> repetitive.
>
>
>
>
>
> Testing
>
> -------
>
>    The parent child classes in the Summary of this JEP should suffice.
>
>
>
> Risks and Assumptions
>
> ---------------------
>
>    I don't see any risks.  I am assuming that this will NOT require a change
> to any bytecode,
>
> only a change to the language.
>
>
>
> Dependencies
>
> ------------
>
>    This would require a change to all Java compliers.
>