Implicit 'this' return for void methods

[Victor Polischuk]

 --- Original message ---
 From: "Marek Kozieł" <develop4lasu at gmail.com>
 Date: 29 March 2014, 18:02:06

> 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..

Even the most simple or advanced tool can be misused. Builders usually mean extra layer which you need to support and adapt in case of underline object has changed. Moreover, just imagine the hell when every object has a proper builder in a separate class or additional methods to JavaBeans properties. 

> While change on void would bring multiple logic spaces take place in line:
> generate .writetofile.generatemore.sendbymail.savetostring...

It looks like function composition and is already used in Stream API and many other places. I really cannot comprehend what is wrong with it.

> 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/

Is that a problem to explain once for "weaker ones" that void methods now MAY be chained?

> Don't get me wrong i like chains but not if language readability would
> suffer, that why i suggested return 'this' :
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000523.html
> But this change is not so easy to introduce.

The change you propose cannot be applied to already compiled legacy code and therefore less useful. Java already has huge code database and rejecting the fact makes the feature unpopular. Imagine some people can desire something like: 

LOG.error("An error occurs: " + e.getMessage()).debug("Print stack trace: ", e);

----
Regards,
Victor Polischuk