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 <mg...@arscreat.com
<mailto: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
<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
