Implicit 'this' return for void methods

[Paul Benedict]

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