<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Another proposal is to use a use-site syntax instead of a declaration site syntax.<br></div><div>By example, Dart uses the syntax ".."<br data-mce-bogus="1"></div><div> new Foo()..setA(12)..setB(42)<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>And this also can be seen as a poor's man substitute for keyword based method calls<br data-mce-bogus="1"></div><div> var foo1 = new FooRecord(a: 12, b: 42);</div><div>and the splat operator<br data-mce-bogus="1"></div><div> var foo2 = new FooRecord(a: 13, ...foo1);<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Tomáš Bleša" <blesa@anneca.cz>, "jdk-dev" <jdk-dev@openjdk.org><br><b>Sent: </b>Sunday, June 25, 2023 6:41:38 PM<br><b>Subject: </b>Re: Method Chaining (enhancing Java syntax)<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4"><font face="monospace">As the replies indicate, this
is a request that comes up periodically, and it is a topic that
has been studied reasonably thoroughly. Before commenting on
the specifics of the various ways to get there (e.g., self
types, special implied this-return treatment for void methods,
etc), let's talk about what the goal is, and whether this is
actually helpful.<br>
<br>
Method chaining has pros and cons, but most developers focus
only on the pros, and specifically, the part where they have to
type fewer characters. As one example, one of the downsides of
chaining is that the type of the intermediate operations are
obscured, such as in:<br>
<br>
stream.map(...)<br>
.sorted()<br>
.findFirst()<br>
.filter(p) <--- here<br>
...<br>
<br>
Unless you are paying careful attention, you may miss the fact
that the .filter() call here a call to Optional::filter, not
Stream::filter. This may or may not be an issue, but the more
chaining you have, the more likely that "calling a different
method than you thought you were" errors can creep in. <br>
<br>
Some APIs are explicitly designed for chaining, such as the
java.util.stream library (Many such APIs are conceptually
builders, even if they are not explicitly cast as such; streams
is such an example.) The example above is usually mostly
harmless, but when we go into CHAIN ALL THE THINGS mode,
especially when we try to apply chaining to libraries that were
not designed for chaining, we are more likely to skate out onto
the edge. All of this is not to say there is not a place for
chaining, but that chaining is not the unalloyed good that many
developers imagine it to be.<br>
<br>
There are typically several sorts of proposals we see for MOAR
CHAINING, in order of increasing hackiness: <br>
<br>
- Introduce a self type. This allows libraries to say what
they mean in libraries like your Shape example. This is a
principled feature that enables richer libraries, but does
little for existing libraries which are full of setters or other
mutative methods, which are often the source of requests like
this. (Even if we had such a feature, these libraries often
cannot change their APIs for reasons of binary compatibility.)<br>
<br>
- Introduce a form of `let` expression that evaluates to a
distinguished binding:<br>
<br>
ArrayList<String> a = let yield x = new
ArrayList<>() in { <br>
a.add(3);<br>
a.add(4);<br>
}<br>
<br>
This combines a traditional functional let-expression (let
<bindings> in <expression>) with nominating one of
the bound expressions as the value of the let body. It is most
useful when you want to create an object, do a bunch of
mutations on it, and then pass the result along. <br>
<br>
- Introduce a feature by which a void method can can say "treat
invocations of me as if they evaluate to the receiver" (I think
this is closest to what you are suggesting today), such as:<br>
<br>
public this-return foo() { ... }<br>
<br>
Such a method would *compile* to a void method, but the language
would treat an invocation of `x.foo()` as evaluating to `x`
rather than void. This has the advantage that you could
compatibly apply `this-return` to existing methods (such as
setters) in a source- and binary-compatible way. <br>
<br>
- Go even farther, and apply the above treatment to *all* void
methods. <br>
<br>
<br>
These proposals are not intrinsically bad, but they are also not
that compelling, because they add complexity for limited
incremental expressiveness. (The self-types one is the most
compelling, but it is also the most significant effort.) <br>
<br>
One reason they are not that compelling (especially the latter
three) is that they largely exist primarily as workarounds for
the following idiom:<br>
<br>
x = new Foo();<br>
x.setA(...);<br>
x.setB(...);<br>
yield x;<br>
<br>
so that all of this can be done as an expression. (I appreciate
the motivation here; expressions are better than statements,
because they compose.)<br>
<br>
This is an idiom that shows up frequently with mutable
JavaBean-style APIs, but both the language and the ecosystem
have been moving away from this style, and so having a
specialized language feature for it is sort of "fighting the
last war." Attila K pointed out that newer APIs can provide (or
you can write your own) methods that have this affect as well:<br>
<br>
static<T> with(T t, Consumer<T> c) {
c.accept(t); return t; }<br>
...<br>
Foo f = with(new Foo(), <br>
f -> { f.setA(3); f.setB(4); });<br>
<br>
(And, in case its not obvious, every language feature competes
with every other one; doing this means not doing something else,
and the "something else" alternatives always seem to be more
compelling.)<br>
<br>
<br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 6/9/2023 12:35 PM, Tomáš Bleša
wrote:<br>
</div>
<blockquote cite="mid:F22932E5-A7E4-4825-99E1-995B3FDF0CFD@anneca.cz">
<div class="" style="font-family: HelveticaNeue;"><font class="" color="#929292"><i class="">/* I sent the following to
discuss@ mailing list yesterday. (wrong list for the topic)
I hope this will be more appropriate mailing list */</i></font></div>
<div class="" style="font-family: HelveticaNeue;"><br class="">
</div>
<div class="" style="font-family: HelveticaNeue;">Hi all,</div>
<div class="" style="font-family: HelveticaNeue;"><br class="">
</div>
<span style="font-family: HelveticaNeue;" class="">this is a
request for feedback on a topic that has been on my mind for a
few weeks. I have written a short document in JEP format and
would like to ask you to comment if you find the described
proposal useful.</span>
<div class="" style="font-family: HelveticaNeue;"><br class="">
</div>
<div class="" style="font-family: HelveticaNeue;">Thanks,</div>
<div class="" style="font-family: HelveticaNeue;">Tomas Blesa</div>
<div class="" style="font-family: HelveticaNeue;">__________________________________</div>
<div class="" style="font-family: HelveticaNeue;"><br class="">
</div>
<div class="">
<div class=""><font class="" face="HelveticaNeue">Summary</font></div>
<div class=""><font class="" face="HelveticaNeue">-------</font></div>
<div class=""><font class="" face="HelveticaNeue">Enhance the
Java language syntax to better support the method chaining
(named parameter idiom) programming pattern.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Goals</font></div>
<div class=""><font class="" face="HelveticaNeue">-----</font></div>
<div class=""><font class="" face="HelveticaNeue">The primary
goal is to remove unnecessary boilerplate code in class
methods designed for type-safe chained calls, especially
when combined with inheritance.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Motivation</font></div>
<div class=""><font class="" face="HelveticaNeue">----------</font></div>
<div class=""><font class="" face="HelveticaNeue">[Method
chaining](<a href="https://en.wikipedia.org/wiki/Method_chaining" class="moz-txt-link-freetext" target="_blank">https://en.wikipedia.org/wiki/Method_chaining</a>)
is a widely used and popular programming pattern,
particularly in creating libraries (APIs) or configuration
objects. Programmers can easily create a method that returns
`this` with a method signature that specifies the returning
type of the containing class.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
Shape scale(double ratio) {</font></div>
<div class=""><font class="" face="HelveticaNeue"> //
recalculate all points</font></div>
<div class=""><font class="" face="HelveticaNeue"> return
this;</font></div>
<div class=""><font class="" face="HelveticaNeue"> }</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">The problem
arises when we combine this pattern with inheritance. We can
lose type information when calling the method on a subclass.
For example, let's create two subclasses of the `Shape`
superclass:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class
Rectangle extends Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
Rectangle roundCorners(double pixels) {</font></div>
<div class=""><font class="" face="HelveticaNeue"> // ...</font></div>
<div class=""><font class="" face="HelveticaNeue"> return
this;</font></div>
<div class=""><font class="" face="HelveticaNeue"> }</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">class Circle
extends Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Now, imagine
the following piece of code using the mini-library above:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">var myRect =
new Rectangle().scale(1.2).roundCorners(10);</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">The code won't
compile because `scale()` returns the type `Shape`, which
doesn't have the `roundCorners` method. There is also a
problem even without the final `roundCorners()` call:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">var myRect =
new Rectangle().scale(1.2);</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">The inferred
type of `myRect` is `Shape` and not `Rectangle`, so the
following line will also be invalid:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">myRect.roundCorners(10);</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Straightforward
solutions to the problem could be:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">1) Override
the `scale()` method in all subclasses and change the return
type:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class
Rectangle extends Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> // ...</font></div>
<div class=""><font class="" face="HelveticaNeue"> @Override</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
Rectangle scale(double ratio) {</font></div>
<div class=""><font class="" face="HelveticaNeue">
super.scale(ratio);</font></div>
<div class=""><font class="" face="HelveticaNeue"> return
this;</font></div>
<div class=""><font class="" face="HelveticaNeue"> } </font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">2) Split
object construction and method calls:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">var myRect =
new Rectangle();</font></div>
<div class=""><font class="" face="HelveticaNeue">myRect.scale(1.2);</font></div>
<div class=""><font class="" face="HelveticaNeue">myRect.roundCorners(10);</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">3) Partial
solution - reorder chained calls (if possible):</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">var myRect =
new Rectangle();</font></div>
<div class=""><font class="" face="HelveticaNeue">myRect.roundCorners(10).scale(1.2);
// roundCorners called first</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">All of these
solutions add unnecessary lines of code, and as the library
of shapes grows, keeping the desired return type will
introduce more and more boilerplate code.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Description</font></div>
<div class=""><font class="" face="HelveticaNeue">-----------</font></div>
<div class=""><font class="" face="HelveticaNeue">The proposed
solution to the problem described in the previous section is
to extend the Java syntax for the returned type in method
signatures:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
this scale(double ratio) { // <=== returns this</font></div>
<div class=""><font class="" face="HelveticaNeue"> //
recalculate all points</font></div>
<div class=""><font class="" face="HelveticaNeue"> return
this;</font></div>
<div class=""><font class="" face="HelveticaNeue"> }</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Methods
declared or defined as returning `this` can only return the
instance on which they are called. The following code will
be type-safe and perfectly valid:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">var myRect =
// inferred Rectangle type</font></div>
<div class=""><font class="" face="HelveticaNeue"> new
Rectangle() // returns Rectangle instance</font></div>
<div class=""><font class="" face="HelveticaNeue">
.scale(1.2) // returns Rectangle instance</font></div>
<div class=""><font class="" face="HelveticaNeue">
.roundCorners(10); // returns Rectangle instance</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">The
constructed type `Rectangle` is preserved throughout the
entire call chain.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">It is possible
to override methods returning `this`, but the subclass'
implementation must also be declared with the `this` keyword
instead of a concrete returning type.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">It is even
possible to remove the explicit return statement altogether:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
this scale(double ratio) {</font></div>
<div class=""><font class="" face="HelveticaNeue"> //
recalculate all points</font></div>
<div class=""><font class="" face="HelveticaNeue"> }</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Or simply
remove the value `this` from the return statement:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
this scale(double ratio) {</font></div>
<div class=""><font class="" face="HelveticaNeue"> //
recalculate all points</font></div>
<div class=""><font class="" face="HelveticaNeue"> if
(condition) return; // <== automatically returns
this</font></div>
<div class=""><font class="" face="HelveticaNeue"> // do
something else</font></div>
<div class=""><font class="" face="HelveticaNeue"> }</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">In fact,
methods returning `this` can be compiled to the same
bytecode as methods returning `void`. This is because the
instance reference (and the returned value) is already known
to the caller, eliminating the need to pass that value back
through the call stack. As a result, both CPU cycles and
memory are saved.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">In the Java
world, it is common to create getters and setters according
to the Java Beans specification in the form of
`getProperty`/`setProperty` pairs or
`isProperty`/`setProperty`. Setters are defined as returning
`void`. These setters can be more useful if defined as
returning `this`:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class Customer
{</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
this setFirstname() { ... }</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
this setSurname() { ... }</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
this setEmail() { ... }</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">This allows
for more concise usage when constructing and configuring an
instance without adding more code:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">customers.add(</font></div>
<div class=""><font class="" face="HelveticaNeue"> new
Customer()</font></div>
<div class=""><font class="" face="HelveticaNeue">
.setFirstname(resultSet.getString(1))</font></div>
<div class=""><font class="" face="HelveticaNeue">
.setSurname(resultSet.getString(2))</font></div>
<div class=""><font class="" face="HelveticaNeue">
.setEmail(resultSet.getString(3))</font></div>
<div class=""><font class="" face="HelveticaNeue">);</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">It is also
possible to declare an interface with methods returning
`this`:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">interface
Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> this
scale(double ratio);</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">In this case,
all implementing classes must define the method as returning
`this`.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">The proposed
syntax is a bit less useful for enums or records, as neither
of them allows for inheritance. But enums and records can
also implement interfaces and for this reason and for
overall consistency, "return this" syntax should be allowed
for enums and records.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">To accommodate
the syntax with the Java Reflection API, it will probably be
required to create a special final placeholder class `This`
(with an uppercase "T"), similar to `java.lang.Void`.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Alternatives</font></div>
<div class=""><font class="" face="HelveticaNeue">------------</font></div>
<div class=""><font class="" face="HelveticaNeue">It is probably
possible to help auto-generate overriding methods in
subclasses using annotation processing, but this option
wasn't fully explored. However, such an approach would add
extra unnecessary code to compiled subclasses and go against
the primary goal of reducing boilerplate.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Risks and
Assumptions</font></div>
<div class=""><font class="" face="HelveticaNeue">---------------------</font></div>
<div class=""><font class="" face="HelveticaNeue">The proposed
syntax is likely to break the compatibility of
library-dependent code whose author decides to switch to the
"return this" syntax between versions.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Older code
that looks like this:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class
MyUglyShape extends Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> @Override</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
MyUglyShape scale(double ratio) {</font></div>
<div class=""><font class="" face="HelveticaNeue"> return
this;</font></div>
<div class=""><font class="" face="HelveticaNeue"> }</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">will have to
be rewritten as:</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class
MyUglyShape extends Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"> @Override</font></div>
<div class=""><font class="" face="HelveticaNeue"> public
this scale(double ratio) { // signature change</font></div>
<div class=""><font class="" face="HelveticaNeue"> //
optional removal of the return this statement</font></div>
<div class=""><font class="" face="HelveticaNeue"> }</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">or </font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">```java</font></div>
<div class=""><font class="" face="HelveticaNeue">class
MyUglyShape extends Shape {</font></div>
<div class=""><font class="" face="HelveticaNeue"><span class="Apple-tab-span" style="white-space:pre"> </span>//
override removed</font></div>
<div class=""><font class="" face="HelveticaNeue">}</font></div>
<div class=""><font class="" face="HelveticaNeue">```</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">This problem
can be mitigated with the help of smart IDEs automatically
suggesting such refactoring.</font></div>
<div class=""><font class="" face="HelveticaNeue"><br class="">
</font></div>
<div class=""><font class="" face="HelveticaNeue">Another
possible risk is breaking old code that relies on the
Reflection API for scanning the returning types of methods.</font></div>
</div>
</blockquote>
<br><br></blockquote></div></div></body></html>