Implicit 'this' return for void methods (original) (raw)

Paul Benedict pbenedict at apache.org
Mon Mar 31 20:44:15 UTC 2014

What about opting in? By that, I mean that these void methods must have a specific TYPE_USE annotation on them at compile time to allow chaining.

This idea would require a JLS update to allow type annotations on void return values -- perhaps exclusive to this annotation.

On Mon, Mar 31, 2014 at 3:06 PM, Marek Kozieł <develop4lasu at gmail.com>wrote:

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/

-- Cheers, Paul

More information about the core-libs-dev mailing list