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 Fri, 25 Aug 2017 00:36:10 GMT
For me a programming language is like a painting, all the parts have to 
fit together to form a whole. The list and map constructors for me do 
not fit the Groovy painting.
Or put it in more computer science, less intuitive terms:
a) The violate the principle of least surprise in a major way (why can I 
"assign" an object of type Foo a List ?)
b) All of these additional ways you can use lists/maps might box you in 
for future syntax extensions
c) They are not powerful, in the sense that you cannot say
final Foo foo = [ 123, [456, [789]] ] // [456] and [789] should also be 
Foo ctor call
unless you can do:
final Foo foo = [ 123, [456, [789] as Foo] as Foo ]
which imho is just terrible...

Not surprising after what I proposed, for me a good syntax for this 
would be:
final foo = Foo(123, Foo(456, Foo(789)))
Where foo has auto-deduced type Foo, and you can think of the "Foo" as 
statically imported factory methods that return Foo instances.

It is hard to imagine a more compact/concise, clearer to read way to 
write this, if you are coming from a C-style syntax background...
Markus


On 24.08.2017 02:35, John Wagenleitner wrote:
> 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 
> <mailto: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
>     <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