Re: Possible New Groovy Features... - Auto final-ize

On 27.08.2017 10:19, Paul King wrote: On Sun, Aug 27, 2017 at 12:57 PM, MG > wrote: On 25.08.2017 04:15, Paul King wrote: Actually, I think an @AutoFinal transform might be a good addition. I'm happy to work on that with you if you like. Let's do

Re: Possible New Groovy Features... - var Keyword

On 27.08.2017 04:41, MG wrote: [...] Flow typing is cool, and I would gather much harder to implement than a "var" keyword (btw, I actually just used the name used by C#, even though picking a different name might be a better choice, to avoid confusion with e.g. Javascript). flow typing is mu

Re: Possible New Groovy Features... - Auto final-ize

On Sun, Aug 27, 2017 at 12:57 PM, MG wrote: > > On 25.08.2017 04:15, Paul King wrote: > > Actually, I think an @AutoFinal transform might be a good addition. I'm > happy to work on that with you if you like. > > Let's do it. > https://issues.apache.org/jira/browse/GROOVY-8300

Re: Possible New Groovy Features... - Auto final-ize

Hi Paul, On 25.08.2017 04:15, Paul King wrote: On Fri, Aug 25, 2017 at 11:03 AM, MG > wrote: I was just referring to your "You can already leave off the "clutter" and apply a CodeNarc rule[1] to detect "bad" style", which seemed to poke fun at my sugge

Re: Possible New Groovy Features... - Deduce the type of final fields from their assigned value

On 25.08.2017 10:09, Jochen Theodorou wrote: for me that is a feature likely to go. If you define a dynamic ctor, it should return an object of at least the type that the ctor is for. I do not care about subclasses or such, but I don't like Date result = new Date() to fail. I did not expect

Re: Possible New Groovy Features... - var Keyword

Hi Jochen, On 25.08.2017 10:05, Jochen Theodorou wrote: On 23.08.2017 00:52, MG wrote: Hi Paul, On 21.08.2017 04:30, Paul King wrote:     Introduce a "var" (o.s.) keyword that allows deduction of type     through assignment:     var device = new PrinterDevice(...) // device variable will h

Re: Possible New Groovy Features... - Auto final-ize

Hi Jochen, On 25.08.2017 10:01, Jochen Theodorou wrote: On 23.08.2017 00:32, MG wrote: [...] Apart from making the code easier to read & safer, it also allows compiler optimizations (and in the absence of a true const-keyword, at least for fundamental data types it has the same effect). Some

Re: Possible New Groovy Features... - Deduce the type of final fields from their assigned value

for me that is a feature likely to go. If you define a dynamic ctor, it should return an object of at least the type that the ctor is for. I do not care about subclasses or such, but I don't like Date result = new Date() to fail. On 25.08.2017 04:28, Paul King wrote: I've only seen it used i

Re: Possible New Groovy Features... - var Keyword

On 23.08.2017 00:52, MG wrote: Hi Paul, On 21.08.2017 04:30, Paul King wrote: Introduce a "var" (o.s.) keyword that allows deduction of type through assignment: var device = new PrinterDevice(...) // device variable will have type PrinterDevice without the need to explictely

Re: Possible New Groovy Features... - Auto final-ize

On 23.08.2017 00:32, MG wrote: [...] Apart from making the code easier to read & safer, it also allows compiler optimizations (and in the absence of a true const-keyword, at least for fundamental data types it has the same effect). Something I want to mention here: The Groovy compiler current

Re: Possible New Groovy Features... - Deduce the type of final fields from their assigned value

I've only seen it used in the context of testing, e.g. where a Map of Closures might be returned instead of the real object. But I don't know what other uses people may have used it for in situations like DSLs. Cheers, Paul. On Fri, Aug 25, 2017 at 11:00 AM, MG wrote: > Ehm - but that is someth

Re: Possible New Groovy Features... - Auto final-ize

On Fri, Aug 25, 2017 at 11:03 AM, MG wrote: > Hi Paul, > > I was just referring to your "You can already leave off the "clutter" and > apply a CodeNarc rule[1] to detect "bad" style", which seemed to poke fun > at my suggestion - and which I did not quite get: What use would a rule be, > if havin

Re: Possible New Groovy Features... - Auto final-ize

Hi Paul, I was just referring to your "You can already leave off the "clutter" and apply a CodeNarc rule[1] to detect "bad" style", which seemed to poke fun at my suggestion - and which I did not quite get: What use would a rule be, if having the clutter that unavoidably comes from having "fi

Re: Possible New Groovy Features... - Deduce the type of final fields from their assigned value

Ehm - but that is something that _should_ fail in my book, since it violates the contract of what a ctor does (namely create an object of his type). I am not saying Groovy should go out of its way to _prevent_ code like this - but if I had to choose between _this_ working and the imho helpful (

Re: Possible New Groovy Features... - ctor calls without new keyword

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

Re: Possible New Groovy Features... - var Keyword

The same argument applies to this as to the 'the type of final fields from their assigned value' case. So, possible perhaps within @CompileStatic contexts. On Wed, Aug 23, 2017 at 8:52 AM, MG wrote: > Hi Paul, > > On 21.08.2017 04:30, Paul King wrote: > > > Introduce a "var" (o.s.) keyword that

Re: Possible New Groovy Features... - Auto final-ize

Forgot the list the first time. On Thu, Aug 24, 2017 at 8:44 PM, Paul King wrote: > > > On Wed, Aug 23, 2017 at 8:32 AM, MG wrote: > >> Hi Paul, >> >> On 21.08.2017 04:30, Paul King wrote: >> >> >> Support making all method/ctor parameters final by default through >> "autofinal" Groovy compiler

Re: Possible New Groovy Features... - Deduce the type of final fields from their assigned value

It might be something that could work with @CompileStatic. For dynamic Groovy, I am not sure this can be done. Consider the following example which, although is dubious style, is valid Groovy: Date.metaClass.constructor = { 42 } final result = new Date() assert result instanceof Integer assert res

Re: Possible New Groovy Features... - ctor calls without new keyword

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 wrote: >

Re: Possible New Groovy Features... - ctor calls without new keyword

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 allocati

Re: Possible New Groovy Features... - var Keyword

Hi Paul, On 21.08.2017 04:30, Paul King wrote: Introduce a "var" (o.s.) keyword that allows deduction of type through assignment: var device = new PrinterDevice(...) // device variable will have type PrinterDevice without the need to explictely state that Rationale: This is

Re: Possible New Groovy Features... - Deduce the type of final fields from their assigned value

Hi Paul, On 21.08.2017 04:30, Paul King wrote: Deduce the type of final fields from their assigned value: class Foo { final device = new PrinterDevice(...) // device field will have type PrinterDevice instead of Object when reflection is used on class Foo } Rationale: Wh

Re: Possible New Groovy Features... - Auto final-ize

Hi Paul, On 21.08.2017 04:30, Paul King wrote: Support making all method/ctor parameters final by default through "autofinal" Groovy compiler flag: 1. Foo(int x, String s) { // final keyword is auto added to all parameters, if compiler flag is set, i.e. this automatically

Re: Possible New Groovy Features...

Hi Paul, thanks for your reply. If I had known you were gonna hit back with so much detail, I would have gone with splitting my mail into multiple parts (but didn't want to spam the mailing list) ;-) I will read up on your links and reply in smaller chunks... Cheers, Markus On 21.08.2017 04

Re: Possible New Groovy Features...

Hi Markus, Thanks for your suggestions. Some neat ideas in your suggestions! Just a general comment to start off with... With language design, it's often the details which are important, so I'd suggest rather than going straight from this email to a bunch of PRs, you'd create separate Jira issues

Possible New Groovy Features...

Hi, before I create change requests, I wanted to ask for some quick feedback on the following potential new Groovy features (I apologize beforehand, if any of these are already covered in some way, and I missed it, or if they have been discussed before, etc - just throwing ideas that I find u