groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniil Ovchinnikov <daniil.ovchinni...@jetbrains.com>
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
JetBrains


> On 5 Sep 2018, at 01:22, Paul King <paulk@asert.com.au> wrote:
> 
> 
> 
> On Wed, Sep 5, 2018 at 2:52 AM Jochen Theodorou <blackdrag@gmx.org <mailto:blackdrag@gmx.org>>
wrote:
> 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
it's
> 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


Mime
View raw message