We may have ‘var’ just to make Java happy in the few occasion of a cut and paste from Java in a Groovy file or we can catch the opportunity to be more “Java like” but staying Groovy with ‘var’ == ‘def’.
I understand both ways, I realise it’s not a decision to be taken easily, but we have the opportunity to implement a new feature writing less code (which is one of my mantras) or writing more code to implement a feature that will be used once in a while to accommodate another language. Let’s keep the door open, I think there is space to innovate instead of following (yes I know this may sound a bit manipulative and maybe it is but it genuinely is my thought) Gianluca Sartori -- Cell. +39 388 1026822 On Thu, 21 Nov 2024 at 22:06, Milles, Eric (TR Technology) via dev < dev@groovy.apache.org> wrote: > When support for var was installed, the path taken was to make it work > more or less like def. That is not to say it is identical to def, since we > did make sure to support the name "var" — reserved type name and not > keyword. This was a fitting choice given our close-to-Java semantics. We > don't want compatibility issues, but some do exist. > > The way def works is to indicate a "dynamic type" in most cases. This is > equivalent to java.lang.Object in many circumstances. > > I understand your request to have var work everywhere that def does so you > can stop using def altogether. > > My preference would be for var to be used for the same local variable > circumstances that Java defines. But we have not implemented the type > inference that Java provides; STC gives a close approximation. > > So if you can use var for field/property, I would consider deprecating and > later removing that. It may not have been intentional since the grammar > shares rules for fields and variables. > > ------------------------------ > *From:* Gianluca Sartori <g.sart...@gmail.com> > *Sent:* Thursday, November 21, 2024 2:39 PM > *To:* dev@groovy.apache.org <dev@groovy.apache.org> > *Subject:* Re: [EXT] Re: Using `var` as method return type placeholder > > If we want Groovy to just accept `var` as it is used in Java we should > also reject an un-initialized variable definition or a "var v = null' since > the type cannot be inferred and it would not be accepted by Java. > > My take on this argument is that "Groovy digests Java but Groovy is not > Java" and instead of talking about "semantics" we may talk about "lexicon' > when discussing about `def` (Python lexicon) and `var` (Java lexicon) but > the semantics remains the same: they are both "type placeholders" in Groovy. > > > > Gianluca Sartori > -- > Cell. +39 388 1026822 > > > On Thu, 21 Nov 2024 at 21:25, Gianluca Sartori <g.sart...@gmail.com> > wrote: > > Using `var` for fields or properties is less meaningful than using `var` > as a type placeholder for methods. I can understand that the word > "(var)iable" is semantically more specific than the word "(def)ine" but it > is not that ugly or alien in method definitions if we think of `var` as a > placeholder for 'Object' (like what is `def` today). > > If we want Groovy to "just" accept and compile Java code we should accept > `var` only for local variables. > > What I am proposing though is that we use `var` as "the new `def`" so if > we want to write code "the Python-ish way" we use `def`, if we want to > write code "the Java-ish way" we use `var`. > > > Gianluca Sartori > -- > Cell. +39 388 1026822 > > > On Thu, 21 Nov 2024 at 20:48, Jonathan Carter <jonathanccar...@gmail.com> > wrote: > > The Oracle docs on var > <https://urldefense.com/v3/__https://docs.oracle.com/en/java/javase/17/language/local-variable-type-inference.html__;!!GFN0sa3rsbfR8OLyAw!fVG_R8uSV1w8CBE28pxva8IPqDXIa3kKPXm4EjFrGpedbb-Pa2pkpPYmYnvElEsS1Xl1-4ATLOWNvnFzCl3pidAa$> > are > helpful, here. Specifically, this part: > > var can be used for the following types of variables: > > > - > > Local variable declarations with initializers: > > - > > Enhanced for-loop indexes: > > - > > Index variables declared in traditional for loops: > > - > > try-with-resources variable: > > - > > Formal parameter declarations of implicitly typed lambda expressions: > A lambda expression whose formal parameters have inferred types is > implicitly typed: > > - > > In JDK 11 and later, you can declare each formal parameter of an > implicitly typed lambda expression with the var identifier: > > > In short, `var` is purely a local variable placeholder in Java. > > Given that Java carefully limited var to work as a reserved type name, not > a keyword to avoid interfering with existing code that used var as a > variable name, I do think there's potential for semantic surprise with Java > if Groovy expands it out to be a synonym for def. The Groovy semantics > <https://urldefense.com/v3/__https://groovy-lang.org/semantics.html__;!!GFN0sa3rsbfR8OLyAw!fVG_R8uSV1w8CBE28pxva8IPqDXIa3kKPXm4EjFrGpedbb-Pa2pkpPYmYnvElEsS1Xl1-4ATLOWNvnFzCgg5WHYn$> > documentation > that Gianluca refers to doesn't really advertise using var for fields or > properties either, even if it does happen to work. Indeed, the warnings > around how type inference works (or doesn't) for fields > <https://urldefense.com/v3/__https://groovy-lang.org/semantics.html*_variables_vs_fields_in_type_inference__;Iw!!GFN0sa3rsbfR8OLyAw!fVG_R8uSV1w8CBE28pxva8IPqDXIa3kKPXm4EjFrGpedbb-Pa2pkpPYmYnvElEsS1Xl1-4ATLOWNvnFzCmjwZaoW$> > makes > me question whether we would want it to. Imagine the case of a Java > developer seeing, "Oh, I can declare a field with var, assign its value > immediately, and get type inference!" only for that to fail. > > I suspect that saying "def and var are basically just Object" probably > isn't helpful in the documentation, and leads to this surprising case that > Gianluca has run into here. This is a subjective case, and what surprises > you depends a lot on your background, but my hunch on the "least > surprising" thing to do for most people would be to document that "var is > only for local variables, just like Java" and treat its validity for fields > as an undocumented, possibly even a deprecated behavior. The note from the > aforementioned doc is relevant: > > Why such a difference? The reason is *thread safety*. At compile time, we > can’t make *any* guarantee about the type of a field. Any thread can > access any field at any time and between the moment a field is assigned a > variable of some type in a method and the time is used the line after, > another thread may have changed the contents of the field. This is not the > case for local variables: we know if they "escape" or not, so we can make > sure that the type of a variable is constant (or not) over time. Note that > even if a field is final, the JVM makes no guarantee about it, so the type > checker doesn’t behave differently if a field is final or not. > > This is one of the reasons why we recommend to use *typed* fields. While > using def for local variables is perfectly fine thanks to type inference, > this is not the case for fields, which also belong to the public API of a > class, hence the type is important. > > > Groovy may be more liberal than Java, but it seems like we'd still want to > steer people away from assuming "type inference works everywhere! I'm > freeeeeeee!" > > Best, > > Jonny > > On Thu, Nov 21, 2024 at 12:27 PM most m <ubermenc...@gmail.com> wrote: > > @Steve Etchelecu > > Java's var is a purely local type placeholder to elide the well-known > verbosity when declaring and initializing variables on the same line, e.g. > so that instead of writing "VeryLongTypename variable = new VeryLongType > name(...);", you could omit the variable's type declaration and leave it be > inferred from the initializer expression. > > I don't think javac considers it valid anywhere except a > declare-and-initialize statement and a foreach loop iterator declaration. > > On Thu, Nov 21, 2024, 20:17 Steve Etchelecu <steve.etchel...@gmail.com> > wrote: > > I thought Gianluca made an excellent argument and helps modernize the > language. Given Groovy’s symbiotic relationship with Java, it seems like > the guidance here should probably be to follow Java’s usage as that likely > keeps friction/confusion to a minimum. > > Not being a Java developer, it isn’t clear to me whether Java supports var > as a return type though I assume it does for consistency. > > On Nov 21, 2024, at 11:10, Milles, Eric (TR Technology) via dev < > dev@groovy.apache.org> wrote: > > > I don't think semantically that "var name() { ... }" makes sense. > > One might argue that var for field and property do not make sense either. > We could explore removing support for var on class members. > ------------------------------ > *From:* Gianluca Sartori <g.sart...@gmail.com> > *Sent:* Thursday, November 21, 2024 10:57 AM > *To:* dev@groovy.apache.org <dev@groovy.apache.org> > *Subject:* [EXT] Re: Using `var` as method return type placeholder > > *External Email:* Use caution with links and attachments. > > Well, actually that's not true, Groovy supports creating fields and > properties as well with `var`, so basically everything `def` does > except return types. > > > Gianluca Sartori > -- > Cell. +39 388 1026822 > > > On Thu, 21 Nov 2024 at 17:41, Daniel Sun <sun...@apache.org> wrote: > > Hi Gianluca, > > `var` was introduced to Groovy just for the better compatibility of > Java. Java just supports declaring variables with `var`, so does Groovy. > > Cheers, > Daniel Sun > > On 2024/11/21 10:37:23 Gianluca Sartori wrote: > > Hello everybody, > > > > My name is Gianluca Sartori, from Italy, I am the author of the open > source > > project Dueuno Elements ( > https://github.com/dueuno-projects/dueuno-elements > <https://urldefense.com/v3/__https://github.com/dueuno-projects/dueuno-elements__;!!GFN0sa3rsbfR8OLyAw!dKLiRGGSN06yuMZYXThMMGLu5ES8nh1240B7mX97feXlJsWHlparG8WQWaFKj2SCDpw5PVXgiTa1KWx0GZNXc3SM$> > ) > > and I am new to this list. > > > > I would like to start using the more Java-ish `var` instead of the > > Python-ish `def` lexicon but I came across the fact that I cannot use > `var` > > as method return type placeholder. > > > > My understanding is that I can use `var` for both local variables and > class > > fields/properties but I cannot use it, for example, if I want to have a > > read only property. The code below does not compile: > > > > class C { > > var firstname > > var lastname > > > > var getFullname() { > > return firstname + ' ' + lastname > > } > > } > > > > var c = new C(firstname: 'Gianluca', lastname: 'Sartori') > > c.fullname > > > > I'd like to switch to using `var` as a type placeholder, but having to > use > > `var` for variable declaration and keep using `def` for methods > definition > > is something I don't understand. I love Groovy because it is easy. This > > restriction of the `var` type placeholder forces me to write code that > > mixes Python lexicon the new Java lexicon. > > > > My main worry is with Grails controllers where we need to define an > action > > using `def` (or `Object`) as return type and define variables in the > method > > body. At the moment we have the following options: > > > > *def* index() { > > *def* myVar = ... > > } > > > > *def* index() { > > *var* myVar = ... > > } > > > > *def* index() { > > *Object* myVar = ... > > } > > > > *Object* index() { > > *def* myVar = ... > > } > > > > *Object* index() { > > *var* myVar = ... > > } > > > > *Object* index() { > > *Object* myVar = ... > > } > > > > I would like to write controllers like this: > > > > *var* index() { > > *var* myVar = ... > > } > > > > to keep the code clean and coherent with the Groovy documentation that > > states clearly that *"If you think of def and var as an alias of Object, > > you will understand in an instant."* > > > > Is this enough of an argument to ask for an implementation of `var` that > is > > fully intrechangable with `def`? > > > > Please let me know what is your opinion on that, > > cheers, > > Gianluca > > > > Gianluca Sartori > > -- > > Cell. +39 388 1026822 > > > >
