groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Possible New Groovy Features... - ctor calls without new keyword
Date Tue, 22 Aug 2017 23:16:44 GMT
Hi Paul,

On 21.08.2017 04:30, Paul King wrote:
> Always allow ctor calls without new keyword:
>

>     final foo = Foo("abc") // creates a new Foo instance by calling
>     Foo class ctor with signature
>     Rationale: new keyword was necessary in C++ to distinguish heap vs
>     stack variable allocation. No such need exists in Groovy, so the
>     keyword just clutters the source code. Naming convention of method
>     names being always lowercase prevents name clashes with methods.
>

>  A partial solution to this is available via @Newify. As far as I 
> know, @Newify hasn't been super popular, so we'd need to think 
> carefully about introducing this.
>

I am not surprised that the @Newify annotation 
(http://docs.groovy-lang.org/latest/html/api/groovy/lang/Newify.html) is 
not popular: When I first read the Groovy documentation (somewhere 
around 1.8.x) and came across @Newify, I was "Yes - fanta... wait... you 
have to do what ?". It felt like a feature that was introduced to kill 
it off immediately...
The Ruby Foo.new(...) syntax falls short for me, since it basically just 
moves the "new" String around, i.e. it does not make the code much more 
readable / compact. And for the Foo(...) style, you have to give the 
classes it shall work for explicitely in the @Newify, which is imho too 
cumbersome.

If @Newify with Foo(...) ctor calls would work without arguments, one 
could apply it through a compiler customizer, so can you tell me the 
rationale for not going down that route (and if the rationale ist still 
valid in 2017 ;-) ), together with the cryptic "The annotation is 
intended to be used sparingly" in the @Newify doc ?

For me, getting rid of "new" would be as Groovy as e.g. dropping the 
semicolon end of line character - which was not necessary since the days 
of K&R - or being able to give the Closure argument like a block 
construct :-)

Now crush my hopes with some 
backward-compatibility-Groovy-insider-error-situations-handler-reason,
Ma;-)rkus



Mime
View raw message