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
