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ł <develop4l...@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 <vict...@ukr.net>: > > --- Original message --- > > From: "Marek Kozieł" <develop4l...@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
