Just thought I'd mention list and map constructors [1], with those you can not only leave out the `new` keyword but also leave off the type (at least on the RHS)
Foo foo = ['abc'] [1] http://groovy-lang.org/semantics.html#_list_and_map_constructors On Tue, Aug 22, 2017 at 4:16 PM, MG <mg...@arscreat.com> wrote: > 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 > > >
