Implicit 'this' return for void methods

Marek Kozieł develop4lasu at
Sat Mar 29 16:00:39 UTC 2014

> The number of cases that this dramatically increases readability are well described.  A single concrete counterexample would help.
I Use Builders which are created especially to be called in chain
mode, so even after a while code is 100% readable. But when we assume
that void could be replaced with this call like:
 Thing thing = new Factory()

Main problem is fact that in long chain you cannot be sure if type
changed and on which object you executing method. Now chain
constructions are so rare that you remember them all.
After such change every call could be considered to be chained so each
code would required more analysis..
Because in one instruction there will be more chance to meet code that
modify and move between classes, and in-line constructions like
a.getB().dosmf().backtoA().doSmf()... would occur.
What more even if chains occurs then there is single logic space in
current calls.
While change on void would bring multiple logic spaces take place in line:
generate .writetofile.generatemore.sendbymail.savetostring...

>> 3rd: space for future return type was left.
> You can’t (shouldn’t) do this.  Changing method return types is a breaking change and will invalidate previously compiled code.  So this is broken already anyway.  However, it is true that this elevates a binary incompatibility to a source incompatibility.
There are interfaces that are not allowed to change mostly between two
modules, but most of methods change types quite often in real-life.
I do not like looking at code from /good developer/ point of view, i
like to look at language with question /how many time good developer
time will be used to help weaker ones/

Don't get me wrong i like chains but not if language readability would
suffer, that why i suggested return 'this' :
But this change is not so easy to introduce.

Marek Kozieł ( Lasu )

More information about the core-libs-dev mailing list