Implicit 'this' return for void methods
develop4lasu at gmail.com
Wed Apr 2 11:52:01 UTC 2014
In my opinion Project Coin was meant only to push some earlier chosen
changes into language.
"Naked dot" in language where long name are preferred is pure evil:
I would have to look pairing ";" for every dot ?
> someVeryLongName()/* explanation*/.otherLongNameMethod();
> someVeryLongName();/* explanation*/.otherLongNameMethod();
When dot would be first sign i would have to:
check end of previous line, or check last sign before comment, some
time i would have to use scroll for each line (like when comparing
code while commit).
> someVeryLongName().call().call().call().call().call().call().call().call().call().call().call(); // comment
> someVeryLongName().call().call().call().call().call().call().call().call().call().call().call() // comment
The things go even worse if code have to be compared without without
It's really hard to find anything good about this proposal.
The most scary is fact that .. or ... would be consumed to support such change.
because i hope for anything near:
2014-04-02 11:08 GMT+02:00 Andrew Haley <aph at redhat.com>:
> On 04/01/2014 10:20 PM, Eirik Lygre wrote:
>> What is the relationship between this "naked dot" proposal and the
>> "chaining of void methods" proposal? The reason for asking is not to be
>> negative, but rather to find out if these issues are best dealt with
>> together, or as independent proposals.
>> I think that if either of these are going to happen, then they must be
>> specified with the appropriate level of isolation: That which belongs
>> together must be processed together; that which belongs apart must be
>> processed apart.
> Point taken, but Project Coin (small language changes) worked well.
Marek Kozieł ( Lasu )
More information about the core-libs-dev