Implicit 'this' return for void methods

[Steven Schlansker]

On Mar 28, 2014, at 10:52 AM, Marek Kozieł <develop4lasu at gmail.com> wrote:

> Hi,
> I really do not know why some proposals are restored back from the
> grave, without answering for questions that was already made:
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000382.html
> 

> Problem lay on interfaces/classes that already exists.
> 'void' have more than one meaning now time:
> 1st: there is no need to return anything.

Sure, but in this case it seems harmless to allow chaining.  In fact that is the entire point of the proposal.  Is there a specific counterpoint where chaining (when used tastefully) is harmful?  I do not think “but some people might misuse it” is a strong enough counter; you could nix almost any useful feature by that argument.

> 2nd: creator wanted to prevent from chaining - to force one line-one
> call formatting.

Why should the creator choose whether I can chain void methods or not?  I am writing the code that is using your library — it is up to me to choose whether chaining methods increases or decreases readability.  At the end of the day if the developer does not have good taste towards readability, there is little the language can do to save him/her.

The number of cases that this dramatically increases readability are well described.  A single concrete counterexample would help.

> 3rd: space for future return type was left.

You can’t (shouldn’t) do this.  Changing method return types is a breaking change and will invalidate previously compiled code.  So this is broken already anyway.  However, it is true that this elevates a binary incompatibility to a source incompatibility.


> 2014-03-28 12:37 GMT+01:00 Ulf Zibis <Ulf.Zibis at cosoco.de>:
>> 
>> Am 28.03.2014 11:05, schrieb Florian Weimer:
>>>> 
>>>>    String mySub =
>>>> myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q"));
>>> 
>>> 
>>> You can already write
>>> 
>>>    String mySub = apply(myVeryLongNamedString,
>>>        (s) -> s.substring(s.indexOf("C"), s.indexOf("Q")))
>>> 
>>> with a helper function like this:
>>> 
>>>    public static <T, R> R apply(T value, Function<T, R> func) {
>>>    return func.apply(value);
>>>    }
>>> 
>>> 
>>> You don't even need to repeat the type.  But the explicit version isn't
>>> too bad, either:
>>> 
>>>    String mySub;
>>>    {
>>>        String s = myVeryLongNamedString;
>>>        mySub = s.substring(s.indexOf("C"), s.indexOf("Q"));
>>>    }
>>> 
>>> So I'm not sure if leading dot expressions are all that helpful.
>> 
>> 
>> Hm, nice hacks, but don't you notice the difference in readability and total
>> amount of code lines in comparison to my proposed one-liner?
>> IMHO the more lines/characters a code has, the more effort is needed to (1)
>> read it and (2) understand it's sense.
>> 
>> BTW, our 2nd example wouldn't work as expression in for loop arguments.
>> 
>> But what for do we discuss the "leading dot expressions" such exhaustive, if
>> there still is no conviction to add the simple "chaining syntax" to the Java
>> language at all?
>> 
>> -Ulf
>> 
> 
> 
> 
> -- 
> Pozdrawiam
> Marek Kozieł ( Lasu )
> 
> http://na-chlodno.blogspot.com/
> http://lasu2string.blogspot.com/