groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wagenleitner <john.wagenleit...@gmail.com>
Subject Re: Possible New Groovy Features... - ctor calls without new keyword
Date Thu, 24 Aug 2017 00:35:02 GMT
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 <mgbiz@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
>
>
>

Mime
View raw message