groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniil Ovchinnikov <>
Subject Re: Constructor call short-hand syntax
Date Wed, 05 Sep 2018 12:54:00 GMT
I didn’t know that it’s a shorthand constructor syntax when I’ve created a ticket. 

I thought it should just work as shorthand for getAt call:
a[1, 2] == a.getAt(1, 2)
a[x: y] == a.getAt(x: y)
a?[1, 2] == a?.getAt(1, 2) // this works already
a?[x: y] == a?.getAt(x: y)

And now I see it as a perfect Groovy-style replacement for @Newify.

Why even @Newify exists if Groovy already had Person[name: “John”, age: 42] syntax?
If such syntax exists, why not extend it to be equivalent to Person.class.getAt(name: “John”,
age: 42), where getAt on a class instance would instantiate a new object ?
The last question implies that getAt would work with any arguments, including named ones.


Daniil Ovchinnikov

> On 5 Sep 2018, at 01:22, Paul King <> wrote:
> On Wed, Sep 5, 2018 at 2:52 AM Jochen Theodorou < <>>
> Am 04.09.2018 um 06:49 schrieb Daniel Sun:
> > Hi Paul,
> > 
> >       Safe index is only for accessing the elements of collections and object
> > properties, but not for creating instance. The collections and objects may
> > be null, so we designed the "safe" index.
> > 
> >       To sum up, I vote -1 to support syntax like `Date[time:0]`, the class
> > instance will not be null.
> I think you actually miss the point a little. Let me rephrase... should 
> we support
> somMap?[x:y]
> for example. I personally think we can take supporting things like 
> x[y:z] and x?[y:z] as future project... if we find a nice use case for this.
> We certainly could ... but we don't have such a proposal in front of us right now, so
> whether we'd like to cater for the current situation in the meantime with an improved
> error message. We could remove such an error message at a future point if we have
> an acceptable proposal.
> Having said that, it's hard to pick up this error case here without also making the
> missing : within a ternary error message look more complex. You'd basically need
> an error message that coped with both cases. Hence my suggestion to close as
> "Won't fix". (But fix up the empty Map edge case only - without safe decorator).
> bye Jochen

View raw message