On Mar 28, 2014, at 10:52 AM, Marek Kozieł <develop4l...@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.zi...@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/

Reply via email to