Implicit 'this' return for void methods

[Marek Kozieł]

Sorry for late answer,

After some thought I came into conclusion, that both solutions are similar.
For me void functionality it to great to be in 100% replaced, other
reasons are not as important.
So if we consider that void would be replaced with 'this' or keep as
void, in additional some type would get void functionality and would
be used as default return value instead of void. Then even with all
confusion this change could be a little reasonable.
void for static void mean next static call ?

For me language should be incremental as much as possible for user as
well for team.
Use case 4 you:
Team member changes void to other type.
Difference between void and void as this is that when someone change
this to other type a lot of work have to be done in order to prevent
potential bugs, even when committed changes are checked  there no easy
way to ensure validity of  all branches and uncommitted code.

2014-03-29 18:42 GMT+01:00 Victor Polischuk <victor2 at ukr.net>:
>  --- 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



-- 
Pozdrawiam
Marek Kozieł ( Lasu )

http://na-chlodno.blogspot.com/
http://lasu2string.blogspot.com/