Re: next generation CliBuilder?

[Remko Popma]

Makes sense.
I’ll run with that.

On Wed, Mar 21, 2018 at 14:48 Paul King  wrote:

> I would suggest (initially) leaving the current annotations and its
> behavior exactly as is. Just replace the commons cli api usage with picocli
> api usage. The same goes for the "dynamic" flavor of using CliBuilder -
> just mimic the current behavior as exactly as possible.
>
> This won't give support for the picocli annotations (unless that came for
> "free") or provide full feature parity but we can add more features over
> time if we want. I would see the first cut as providing an extra level of
> Groovy friendliness over and above "vanilla" picocli for the common cases.
> There is nothing stopping people from using picocli directly if they need
> the other features and we could add more features like an "index"
> attribute to @Unparsed at our leisure in a backward compatible way.
>
> What do you think?
>
> Paul.
>
>
> On Wed, Mar 21, 2018 at 2:38 PM, Remko Popma 
> wrote:
>
>>
>> On Wed, Mar 21, 2018 at 12:43 Paul King  wrote:
>>
>>> On Wed, Mar 21, 2018 at 11:11 AM, Paul King  wrote:
>>>
 Picocli has always looked like a nice alternative. It wasn't an option
 for me before it had the api but picocli 3 seems to have that covered. The
 jar is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder
 supports strong typing for options at the api level without having to
 specify a default value. I don't think the picocli api supports this but
 neither did commons cli, so perhaps that can be catered for in a reworked
 CliBuilder similar to how we do it now.

 My main reservation is we haven't received a lot of feedback on our
 existing annotations API and strong typing support in 2.5. But if we had a
 fully backward compatible drop-in replacement, I wouldn't be against it.

>>>
>>> And, I guess if we had a solution in the next month, full compatibility
>>> with the yet to be released 2.5 features would be less of a concern.
>>>
>>
>> Next month should be possible.
>>
>> There is certainly some overlap between the groovy.cli.Option annotation
>> introduced in groovy 2.5 alpha and the picocli Option annotation. Are you
>> thinking the groovy.cli.Option could be replaced by the picocli annotation
>> or should the new CliBuilder support both?
>>
>> Supporting both means remaining compatible with the groovy 2.5 alpha API,
>> but there is no groovy equivalent of the picocli annotations for commands
>> and typed positional parameters, so the set of groovy.cli annotations would
>> not be as coherent or full-featured.
>>
>> Either is possible, it's just where you want to take this in the future.
>> I'm already happy with your positive response.
>>
>>
>>>
 Cheers, Paul.

 On Wed, Mar 21, 2018 at 5:09 AM, MG  wrote:

> Hi Russell,
>
> I have not tried picocli myself, but strongly typed parameters + good
> looking annotations API + actively maintained + Groovy enthusiast offering
> to integrate it into Groovy sounds good to me... ||-)
>
> Does anyone knows of any shortcomings of picocli or miss some CLI
> features in the library ? Or are there any other (long running) plans to
> replace the existing CliBuilder implementation ?
>
> Cheers,
> mg
>
>
>
> On 20.03.2018 19:13, Russel Winder wrote:
>
>> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>>
>>> Would there be any interest in a next generation CliBuilder that is
>>> based on [picocli][1] instead of commons-cli?
>>>
>> Personally I am all for a new CLI system for Groovy.  There are though
>> many different CLI frameworks already out there, many have previously
>> been discussed in various threads on this list. Indeed I think there
>> has been some work, but none that got absorbed into the standard
>> Groovy
>> distribution.
>>
>> So the question for me is not how to replace commons-cli just what to
>> do. So the question for me is what distinguishes picocli from all the
>> other options.
>>
>> […]
>>>
>>
>

>

Re: next generation CliBuilder?

[Paul King]

I would suggest (initially) leaving the current annotations and its
behavior exactly as is. Just replace the commons cli api usage with picocli
api usage. The same goes for the "dynamic" flavor of using CliBuilder -
just mimic the current behavior as exactly as possible.

This won't give support for the picocli annotations (unless that came for
"free") or provide full feature parity but we can add more features over
time if we want. I would see the first cut as providing an extra level of
Groovy friendliness over and above "vanilla" picocli for the common cases.
There is nothing stopping people from using picocli directly if they need
the other features and we could add more features like an "index" attribute
to @Unparsed at our leisure in a backward compatible way.

What do you think?

Paul.


On Wed, Mar 21, 2018 at 2:38 PM, Remko Popma  wrote:

>
> On Wed, Mar 21, 2018 at 12:43 Paul King  wrote:
>
>> On Wed, Mar 21, 2018 at 11:11 AM, Paul King  wrote:
>>
>>> Picocli has always looked like a nice alternative. It wasn't an option
>>> for me before it had the api but picocli 3 seems to have that covered. The
>>> jar is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder
>>> supports strong typing for options at the api level without having to
>>> specify a default value. I don't think the picocli api supports this but
>>> neither did commons cli, so perhaps that can be catered for in a reworked
>>> CliBuilder similar to how we do it now.
>>>
>>> My main reservation is we haven't received a lot of feedback on our
>>> existing annotations API and strong typing support in 2.5. But if we had a
>>> fully backward compatible drop-in replacement, I wouldn't be against it.
>>>
>>
>> And, I guess if we had a solution in the next month, full compatibility
>> with the yet to be released 2.5 features would be less of a concern.
>>
>
> Next month should be possible.
>
> There is certainly some overlap between the groovy.cli.Option annotation
> introduced in groovy 2.5 alpha and the picocli Option annotation. Are you
> thinking the groovy.cli.Option could be replaced by the picocli annotation
> or should the new CliBuilder support both?
>
> Supporting both means remaining compatible with the groovy 2.5 alpha API,
> but there is no groovy equivalent of the picocli annotations for commands
> and typed positional parameters, so the set of groovy.cli annotations would
> not be as coherent or full-featured.
>
> Either is possible, it's just where you want to take this in the future.
> I'm already happy with your positive response.
>
>
>>
>>> Cheers, Paul.
>>>
>>> On Wed, Mar 21, 2018 at 5:09 AM, MG  wrote:
>>>
 Hi Russell,

 I have not tried picocli myself, but strongly typed parameters + good
 looking annotations API + actively maintained + Groovy enthusiast offering
 to integrate it into Groovy sounds good to me... ||-)

 Does anyone knows of any shortcomings of picocli or miss some CLI
 features in the library ? Or are there any other (long running) plans to
 replace the existing CliBuilder implementation ?

 Cheers,
 mg



 On 20.03.2018 19:13, Russel Winder wrote:

> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>
>> Would there be any interest in a next generation CliBuilder that is
>> based on [picocli][1] instead of commons-cli?
>>
> Personally I am all for a new CLI system for Groovy.  There are though
> many different CLI frameworks already out there, many have previously
> been discussed in various threads on this list. Indeed I think there
> has been some work, but none that got absorbed into the standard Groovy
> distribution.
>
> So the question for me is not how to replace commons-cli just what to
> do. So the question for me is what distinguishes picocli from all the
> other options.
>
> […]
>>
>

>>>

Re: next generation CliBuilder?

[Remko Popma]

On Wed, Mar 21, 2018 at 12:43 Paul King  wrote:

> On Wed, Mar 21, 2018 at 11:11 AM, Paul King  wrote:
>
>> Picocli has always looked like a nice alternative. It wasn't an option
>> for me before it had the api but picocli 3 seems to have that covered. The
>> jar is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder
>> supports strong typing for options at the api level without having to
>> specify a default value. I don't think the picocli api supports this but
>> neither did commons cli, so perhaps that can be catered for in a reworked
>> CliBuilder similar to how we do it now.
>>
>> My main reservation is we haven't received a lot of feedback on our
>> existing annotations API and strong typing support in 2.5. But if we had a
>> fully backward compatible drop-in replacement, I wouldn't be against it.
>>
>
> And, I guess if we had a solution in the next month, full compatibility
> with the yet to be released 2.5 features would be less of a concern.
>

Next month should be possible.

There is certainly some overlap between the groovy.cli.Option annotation
introduced in groovy 2.5 alpha and the picocli Option annotation. Are you
thinking the groovy.cli.Option could be replaced by the picocli annotation
or should the new CliBuilder support both?

Supporting both means remaining compatible with the groovy 2.5 alpha API,
but there is no groovy equivalent of the picocli annotations for commands
and typed positional parameters, so the set of groovy.cli annotations would
not be as coherent or full-featured.

Either is possible, it's just where you want to take this in the future.
I'm already happy with your positive response.


>
>> Cheers, Paul.
>>
>> On Wed, Mar 21, 2018 at 5:09 AM, MG  wrote:
>>
>>> Hi Russell,
>>>
>>> I have not tried picocli myself, but strongly typed parameters + good
>>> looking annotations API + actively maintained + Groovy enthusiast offering
>>> to integrate it into Groovy sounds good to me... ||-)
>>>
>>> Does anyone knows of any shortcomings of picocli or miss some CLI
>>> features in the library ? Or are there any other (long running) plans to
>>> replace the existing CliBuilder implementation ?
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>
>>> On 20.03.2018 19:13, Russel Winder wrote:
>>>
 On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:

> Would there be any interest in a next generation CliBuilder that is
> based on [picocli][1] instead of commons-cli?
>
 Personally I am all for a new CLI system for Groovy.  There are though
 many different CLI frameworks already out there, many have previously
 been discussed in various threads on this list. Indeed I think there
 has been some work, but none that got absorbed into the standard Groovy
 distribution.

 So the question for me is not how to replace commons-cli just what to
 do. So the question for me is what distinguishes picocli from all the
 other options.

 […]
>

>>>
>>

Re: next generation CliBuilder?

[Paul King]

On Wed, Mar 21, 2018 at 11:11 AM, Paul King  wrote:

> Picocli has always looked like a nice alternative. It wasn't an option for
> me before it had the api but picocli 3 seems to have that covered. The jar
> is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder supports
> strong typing for options at the api level without having to specify a
> default value. I don't think the picocli api supports this but neither did
> commons cli, so perhaps that can be catered for in a reworked CliBuilder
> similar to how we do it now.
>
> My main reservation is we haven't received a lot of feedback on our
> existing annotations API and strong typing support in 2.5. But if we had a
> fully backward compatible drop-in replacement, I wouldn't be against it.
>

And, I guess if we had a solution in the next month, full compatibility
with the yet to be released 2.5 features would be less of a concern.


> Cheers, Paul.
>
> On Wed, Mar 21, 2018 at 5:09 AM, MG  wrote:
>
>> Hi Russell,
>>
>> I have not tried picocli myself, but strongly typed parameters + good
>> looking annotations API + actively maintained + Groovy enthusiast offering
>> to integrate it into Groovy sounds good to me... ||-)
>>
>> Does anyone knows of any shortcomings of picocli or miss some CLI
>> features in the library ? Or are there any other (long running) plans to
>> replace the existing CliBuilder implementation ?
>>
>> Cheers,
>> mg
>>
>>
>>
>> On 20.03.2018 19:13, Russel Winder wrote:
>>
>>> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>>>
 Would there be any interest in a next generation CliBuilder that is
 based on [picocli][1] instead of commons-cli?

>>> Personally I am all for a new CLI system for Groovy.  There are though
>>> many different CLI frameworks already out there, many have previously
>>> been discussed in various threads on this list. Indeed I think there
>>> has been some work, but none that got absorbed into the standard Groovy
>>> distribution.
>>>
>>> So the question for me is not how to replace commons-cli just what to
>>> do. So the question for me is what distinguishes picocli from all the
>>> other options.
>>>
>>> […]

>>>
>>
>

Re: [RFE] Methods as expressions

[Daniel Sun]

Hi Cédric,

 If method throws exception, what does your proposed syntax look like?
For example,


```
def m(String x, Integer y) throws IOException {
readSomeFile(..)
}
```

is equivalent to the following code?

```
def m(String x, Integer y) throws IOException = readSomeFile(..)
```

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: next generation CliBuilder?

[Paul King]

Picocli has always looked like a nice alternative. It wasn't an option for
me before it had the api but picocli 3 seems to have that covered. The jar
is bigger (193k vs 53k) but perhaps not a huge issue. CliBuilder supports
strong typing for options at the api level without having to specify a
default value. I don't think the picocli api supports this but neither did
commons cli, so perhaps that can be catered for in a reworked CliBuilder
similar to how we do it now.

My main reservation is we haven't received a lot of feedback on our
existing annotations API and strong typing support in 2.5. But if we had a
fully backward compatible drop-in replacement, I wouldn't be against it.

Cheers, Paul.

On Wed, Mar 21, 2018 at 5:09 AM, MG  wrote:

> Hi Russell,
>
> I have not tried picocli myself, but strongly typed parameters + good
> looking annotations API + actively maintained + Groovy enthusiast offering
> to integrate it into Groovy sounds good to me... ||-)
>
> Does anyone knows of any shortcomings of picocli or miss some CLI features
> in the library ? Or are there any other (long running) plans to replace the
> existing CliBuilder implementation ?
>
> Cheers,
> mg
>
>
>
> On 20.03.2018 19:13, Russel Winder wrote:
>
>> On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:
>>
>>> Would there be any interest in a next generation CliBuilder that is
>>> based on [picocli][1] instead of commons-cli?
>>>
>> Personally I am all for a new CLI system for Groovy.  There are though
>> many different CLI frameworks already out there, many have previously
>> been discussed in various threads on this list. Indeed I think there
>> has been some work, but none that got absorbed into the standard Groovy
>> distribution.
>>
>> So the question for me is not how to replace commons-cli just what to
>> do. So the question for me is what distinguishes picocli from all the
>> other options.
>>
>> […]
>>>
>>
>

Re: [RFE] Methods as expressions

[MG]

On 20.03.2018 17:16, David Dawson wrote:

To give an alternate take on the topic.

The best thing in Groovy when it first started gaining adoption was this

["hello"], "world"].collect {
  it * 2
}.each { println it }

Utterly incompatible with Java, happily destroying its idioms. 
Collection literals, closures, removing parans, functional chaining. 
Source compatibility was nice, but proper two way interaction in the 
object models was better.


I agree that that was one of the features that drew me to Groovy. But I 
never felt that it did break with or deviate from Java syntax - quite 
the contrary, I immediately felt at home using this syntax, since it 
felt like a organic extension.
The syntax is in general one of the strenghts of Groovy for me: It has 
"somehow" managed to avoid falling into the many syntax pitfalls that 
other languages so often exhibit (e.g. var/val in Scala I have already 
posted; Python is just weird, with its underscores and indentation 
having semantic meaning; Ruby supports curly braces and Algol begin/end; 
Basic is a car crash from start to finish; etc).
I have programmed in 6502/68000 assembler to Occam, and we could all be 
programming in Brainfuck (https://en.wikipedia.org/wiki/Brainfuck) or 
Whitespace 
(https://en.wikipedia.org/wiki/Whitespace_(programming_language)). 
Humans are adaptable. But a powerful, clear, logical, compact/concisce, 
while still well to comprehend/read syntax which helps in minimizing 
programming errors is a clear advantage.


I came to Groovy originally to gain access to the above, and stayed 
because I could go quicker and still read what I'd written afterwards. 
I've used a raft of languages and, to me at least, expression oriented 
syntax is a boon for lots of styles of development and problems. 
Adopting aspects of that into Groovy, in the pragmatic way that Groovy 
gives us, would be great, for me at least.


The suggested extension as I understand it is only syntactic sugar, to 
be able to write "= ..." instead of "{ ... }" to define simple function 
bodies. It does not extend Groovy's capabilities in any way.
Are you thinking more along the line of first order functions support 
(outside of Groovy's existing closures and upcoming Groovy 3.0 Java 
style lambdas):

final handler = String fun(String s, int i, x) { ... }
or
final handler = String _(String s, int i, x) { ... }
?

This is broader than the email chain may warrant, sorry if it is and 
hopefully it doesn't drag things off track, but I always pay attention 
when I see someone proposing substantial new things in Groovy. Perhaps 
what's needed is a broader conversation on the philosophical direction 
of Groovy. Is it just to be Java+, or something else?   I'd like it to 
regain something of the lead it once had in raw productivity features 
and good, strong language features to adopt.    I know that lambdas 
burned the community a bit by causing a break in compatibility with 
Java for so long, but since we've got Parrot integrated, and that gap 
closed, it strikes me that of all times, now is the time for the 
Groovy community to be bolder about the direction it can go in.


Thinking/discussing is always good in my book: What big and bold 
directions did you have in mind ? :-)

Re: [RFE] Methods as expressions

[MG]

On 20.03.2018 16:19, eric.mil...@thomsonreuters.com wrote:


Java syntax for a default method value is:

public@interfaceDelegate{

boolean*interfaces*() defaulttrue;

Is there really a need to introduce another form when the saving is 
actially 0 characters (colon and equals vs open and close brace)?


class Foo {

    fun truth(): Integer = 42

}

  vs.

class Foo {

    Integer truth() { 42 }

}



I do not think the suggestion was to introduce Kotlin method declaration 
syntax (Which looks like JavaScript, and, as I've said before imho makes 
little sense in a statically typed language) in general, but "just" the 
assignment part instead of giving a code block.



(I always felt that the syntax chosen in Java (and therfore Groovy) for 
declaring default paramters in annotations is odd: Why does the 
parameter name need to be given looking like a parmeterless method 
defintion ? Why do we need a "default" keyword ?
Generally speaking, the syntax does not fit well with existing syntax. 
Having:


public@interfaceDelegate{

boolean*interfaces* =true

would imho have made much more sense, since it looks like a class field 
initialization (interfaces do not support fields, of course, but in the 
long run that is a weak reason to go along the route that was choosen).)




What about the difference in named parameters in annotations vs. methods?

@Anno(name = value)

def foo = bar(name: value)

Could the map-entry syntax be supported for annotations to normalize 
named parameters?




I think the unifying aspect here is assignment to 
variables/parameters/fields, not naming.
Since no one will suggest that we replace the assignment operator "=" in 
Groovy with ":", I think it would therfore be better to move into the 
opposite direction, and  replace the mape-entry syntax for named 
parameters with an assignment syntax (while extending its functionality: 
https://issues.apache.org/jira/browse/GROOVY-8451) - thereby making it 
compatible with assignment in general and the definition of default 
parameters.

Re: next generation CliBuilder?

[MG]

Hi Russell,

I have not tried picocli myself, but strongly typed parameters + good 
looking annotations API + actively maintained + Groovy enthusiast 
offering to integrate it into Groovy sounds good to me... ||-)


Does anyone knows of any shortcomings of picocli or miss some CLI 
features in the library ? Or are there any other (long running) plans to 
replace the existing CliBuilder implementation ?


Cheers,
mg


On 20.03.2018 19:13, Russel Winder wrote:

On Wed, 2018-03-21 at 02:26 +0900, Remko Popma wrote:

Would there be any interest in a next generation CliBuilder that is
based on [picocli][1] instead of commons-cli?

Personally I am all for a new CLI system for Groovy.  There are though
many different CLI frameworks already out there, many have previously
been discussed in various threads on this list. Indeed I think there
has been some work, but none that got absorbed into the standard Groovy
distribution.

So the question for me is not how to replace commons-cli just what to
do. So the question for me is what distinguishes picocli from all the
other options.


[…]

Re: next generation CliBuilder?

[MG]

+1 from my side :-)

On 20.03.2018 18:26, Remko Popma wrote:

Would there be any interest in a next generation CliBuilder that is
based on [picocli][1] instead of commons-cli?

This would enable new features like:
* support for nested [subcommands][2]
* strongly typed [positional parameters][3]
* command line [autocompletion][4]
* [ANSI colors][5] in usage help message

Picocli is actively maintained and developed. The next major
release (3.0) includes a [programmatic API][6] in addition
to the annotations API.

If there is any interest, I would be happy to do the work
to develop, create tests and document such a next generation
CliBuilder (CliBuilder2?). I was thinking to try to make the
API very similar to the current CliBuilder to facilitate user
migration, but I am open to suggestions.

Thoughts?

[1]: https://github.com/remkop/picocli
[2]: http://picocli.info/index.html#_subcommands
[3]: http://picocli.info/index.html#_positional_parameters
[4]: http://picocli.info/autocomplete.html
[5]: http://picocli.info/index.html#_ansi_colors_and_styles
[6]: https://github.com/remkop/picocli/wiki/Programmatic-API

next generation CliBuilder?

[Remko Popma]

Would there be any interest in a next generation CliBuilder that is
based on [picocli][1] instead of commons-cli?

This would enable new features like:
* support for nested [subcommands][2]
* strongly typed [positional parameters][3]
* command line [autocompletion][4]
* [ANSI colors][5] in usage help message

Picocli is actively maintained and developed. The next major
release (3.0) includes a [programmatic API][6] in addition
to the annotations API.

If there is any interest, I would be happy to do the work
to develop, create tests and document such a next generation
CliBuilder (CliBuilder2?). I was thinking to try to make the
API very similar to the current CliBuilder to facilitate user
migration, but I am open to suggestions.

Thoughts?

[1]: https://github.com/remkop/picocli
[2]: http://picocli.info/index.html#_subcommands
[3]: http://picocli.info/index.html#_positional_parameters
[4]: http://picocli.info/autocomplete.html
[5]: http://picocli.info/index.html#_ansi_colors_and_styles
[6]: https://github.com/remkop/picocli/wiki/Programmatic-API

Re: [RFE] Methods as expressions

[David Dawson]

To give an alternate take on the topic.

The best thing in Groovy when it first started gaining adoption was this

["hello"], "world"].collect {
  it * 2
}.each { println it }

Utterly incompatible with Java, happily destroying its idioms. Collection
literals, closures, removing parans, functional chaining. Source
compatibility was nice, but proper two way interaction in the object models
was better.

I came to Groovy originally to gain access to the above, and stayed because
I could go quicker and still read what I'd written afterwards. I've used a
raft of languages and, to me at least, expression oriented syntax is a boon
for lots of styles of development and problems. Adopting aspects of that
into Groovy, in the pragmatic way that Groovy gives us, would be great, for
me at least.

This is broader than the email chain may warrant, sorry if it is and
hopefully it doesn't drag things off track, but I always pay attention when
I see someone proposing substantial new things in Groovy. Perhaps what's
needed is a broader conversation on the philosophical direction of Groovy.
Is it just to be Java+, or something else?   I'd like it to regain
something of the lead it once had in raw productivity features and good,
strong language features to adopt.I know that lambdas burned the
community a bit by causing a break in compatibility with Java for so long,
but since we've got Parrot integrated, and that gap closed, it strikes me
that of all times, now is the time for the Groovy community to be  bolder
about the direction it can go in.


On 20 March 2018 at 15:19,  wrote:

> Java syntax for a default method value is:
>
> public @interface Delegate {
>
> boolean *interfaces*() default true;
>
>
>
>
>
> Is there really a need to introduce another form when the saving is
> actially 0 characters (colon and equals vs open and close brace)?
>
>
>
> class Foo {
>
> fun truth(): Integer = 42
>
> }
>
>   vs.
>
> class Foo {
>
> Integer truth() { 42 }
>
> }
>
>
>
>
>
> What about the difference in named parameters in annotations vs. methods?
>
>
>
> @Anno(name = value)
>
> def foo = bar(name: value)
>
>
>
> Could the map-entry syntax be supported for annotations to normalize named
> parameters?
>
>
>
> *From:* mg [mailto:mg...@arscreat.com]
> *Sent:* Tuesday, March 20, 2018 7:11 AM
> *To:* dev@groovy.apache.org
> *Subject:* Re: [RFE] Methods as expressions
>
>
>
> I agree with the proper functions in principle, but in this case it  would
> be "special syntax for a special, limited case" which to me is the (non
> desirable) C# way of doing things...
>
> In any case it would imho be good to see what actually comes out of Java
> in this regard, instead of making Groovy Kotlin compatible now
>
>
>
>
>
>  Ursprüngliche Nachricht 
>
> Von: David Dawson 
>
> Datum: 20.03.18 13:00 (GMT+01:00)
>
> An: dev@groovy.apache.org
>
> Betreff: Re: [RFE] Methods as expressions
>
>
>
> I personally agree with Cedric, having the intent of "proper" functions
> would be useful. Perhaps the = could be replaced, but I certainly like the
> idea of having more expression oriented syntax in Groovy.
>
> Java itself seems to be moving in this direction with the proposed switch
> expression syntax?  This feels very similar?
>
>
>
> On 20 March 2018 at 11:39, mg  wrote:
>
> @style rules: Then change your style rules to allow single line single
> statement blocks, do not change the language, no ?-)
>
>
>
>  Ursprüngliche Nachricht 
>
> Von: Cédric Champeau 
>
> Datum: 20.03.18 12:23 (GMT+01:00)
>
> An: dev@groovy.apache.org
>
> Betreff: Re: [RFE] Methods as expressions
>
>
>
> Again that's a declaration of intent (if you put apart the fact that you
> can have style rules that force you to put the brackets on new lines).
>
> When I write:
>
> double surface(double x, double y) = x * y
>
> It's very clear what the intent of this is. It's an expression, a
> _function_. On the other hand, { ... } declares a block, that could
> represent an expression, or a statement, or a list of statements, one of
> them returning an expression. I like the declaration of intent.
>
>
>
> 2018-03-20 12:20 GMT+01:00 mg :
>
> Am having a migraine right now so hard to concentrate / think straight but
> it seems all that syntax does is getting rid of a single character ?
>
>
>
> Integer truth() { 42 }
>
>
>
> could then be written as
>
>
>
> Integer truth() = 42
>
>
>
>
>
> or
>
>
>
> String hello(String name) { "Hello $name" }
>
>
>
> String hello(String name) = Hello $name"
>
>
>
> (why did you use a return keyword in your sample ?)
>
>
>
> I dont see an improvement in readability here - the main "advantage" is
> that curly braces are annoying to input on non-US keyboard layouts ;-)
>
>
>
> mg
>
>
>
>
>
>
>
>  Ursprüngliche Nachricht 
>
> Von: Cédric Champeau 

RE: [RFE] Methods as expressions

[eric.milles]

Java syntax for a default method value is:
public @interface Delegate {
boolean interfaces() default true;


Is there really a need to introduce another form when the saving is actially 0 
characters (colon and equals vs open and close brace)?

class Foo {
fun truth(): Integer = 42
}
  vs.
class Foo {
Integer truth() { 42 }
}


What about the difference in named parameters in annotations vs. methods?

@Anno(name = value)
def foo = bar(name: value)

Could the map-entry syntax be supported for annotations to normalize named 
parameters?

From: mg [mailto:mg...@arscreat.com]
Sent: Tuesday, March 20, 2018 7:11 AM
To: dev@groovy.apache.org
Subject: Re: [RFE] Methods as expressions

I agree with the proper functions in principle, but in this case it  would be 
"special syntax for a special, limited case" which to me is the (non desirable) 
C# way of doing things...
In any case it would imho be good to see what actually comes out of Java in 
this regard, instead of making Groovy Kotlin compatible now


 Ursprüngliche Nachricht 
Von: David Dawson 
>
Datum: 20.03.18 13:00 (GMT+01:00)
An: dev@groovy.apache.org
Betreff: Re: [RFE] Methods as expressions

I personally agree with Cedric, having the intent of "proper" functions would 
be useful. Perhaps the = could be replaced, but I certainly like the idea of 
having more expression oriented syntax in Groovy.
Java itself seems to be moving in this direction with the proposed switch 
expression syntax?  This feels very similar?


On 20 March 2018 at 11:39, mg > 
wrote:
@style rules: Then change your style rules to allow single line single 
statement blocks, do not change the language, no ?-)

 Ursprüngliche Nachricht 
Von: Cédric Champeau 
>
Datum: 20.03.18 12:23 (GMT+01:00)
An: dev@groovy.apache.org
Betreff: Re: [RFE] Methods as expressions

Again that's a declaration of intent (if you put apart the fact that you can 
have style rules that force you to put the brackets on new lines).
When I write:
double surface(double x, double y) = x * y
It's very clear what the intent of this is. It's an expression, a _function_. 
On the other hand, { ... } declares a block, that could represent an 
expression, or a statement, or a list of statements, one of them returning an 
expression. I like the declaration of intent.

2018-03-20 12:20 GMT+01:00 mg >:
Am having a migraine right now so hard to concentrate / think straight but it 
seems all that syntax does is getting rid of a single character ?

Integer truth() { 42 }

could then be written as

Integer truth() = 42


or

String hello(String name) { "Hello $name" }

String hello(String name) = Hello $name"

(why did you use a return keyword in your sample ?)

I dont see an improvement in readability here - the main "advantage" is that 
curly braces are annoying to input on non-US keyboard layouts ;-)

mg



 Ursprüngliche Nachricht 
Von: Cédric Champeau 
>
Datum: 20.03.18 11:41 (GMT+01:00)
An: dev@groovy.apache.org
Betreff: [RFE] Methods as expressions

Hi,
One of the Kotlin features I really like is the short-hand notation for simple 
expression methods:

class Foo {
fun truth(): Integer = 42
}

For example, in Groovy, you write:



@Controller("/") class HelloController {

@Get("/hello/{name}")
String hello(String name) {
return "Hello $name"
}
}

but we could write:



@Controller("/")
class HelloController {
@Get("/hello/{name}")
String hello(String name) = "Hello $name"
}

It's more concise and makes the "functional style" more readable. Is this 
something Groovy users would appreciate?

Re: [RFE] Methods as expressions

[Daniel.Sun]

Hi  Cédric,

  +1.  I would like to hear what other groovy users say.

P.S. Your proposal  should be not difficult to implement in Parrot parser.

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [RFE] Methods as expressions

[mg]

I agree with the proper functions in principle, but in this case it  would be 
"special syntax for a special, limited case" which to me is the (non desirable) 
C# way of doing things...In any case it would imho be good to see what actually 
comes out of Java in this regard, instead of making Groovy Kotlin compatible now


 Ursprüngliche Nachricht Von: David Dawson 
 Datum: 20.03.18  13:00  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: Re: [RFE] Methods as expressions 
I personally agree with Cedric, having the intent of "proper" functions would 
be  useful. Perhaps the = could be replaced, but I certainly like the idea of 
having more expression oriented syntax in Groovy.

Java itself seems to be moving in this direction with the proposed switch 
expression syntax?  This feels very similar?



On 20 March 2018 at 11:39, mg  wrote:
@style rules: Then change your style rules to allow single line single 
statement blocks, do not change the language, no ?-)
 Ursprüngliche Nachricht Von: Cédric Champeau 
 Datum: 20.03.18  12:23  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: Re: [RFE] Methods as expressions 
Again that's a declaration of intent (if you put apart the fact that you can 
have style rules that force you to put the brackets on new lines).

When I write:

double surface(double x, double y) = x * y

It's very clear what the intent of this is. It's an expression, a _function_. 
On the other hand, { ... } declares a block, that could represent an 
expression, or a statement, or a list of statements, one of them returning an 
expression. I like the declaration of intent.

2018-03-20 12:20 GMT+01:00 mg :
Am having a migraine right now so hard to concentrate / think straight but it 
seems all that syntax does is getting rid of a single character ?
Integer truth() { 42 }
could then be written as
Integer truth() = 42

or
String hello(String name) { "Hello $name" }
String hello(String name) = Hello $name"
(why did you use a return keyword in your sample ?)
I dont see an improvement in readability here - the main "advantage" is that 
curly braces are annoying to input on non-US keyboard layouts ;-)
mg


 Ursprüngliche Nachricht Von: Cédric Champeau 
 Datum: 20.03.18  11:41  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: [RFE] Methods as expressions 
Hi,

One of the Kotlin features I really like is the short-hand notation for simple 
expression methods:

class Foo {
    fun truth(): Integer = 42
}

For example, in Groovy, you write:

@Controller("/") class HelloController {

@Get("/hello/{name}") 
String hello(String name) {
return "Hello $name"
}
}
but we could write:

@Controller("/") 
class HelloController {
@Get("/hello/{name}") 
String hello(String name) = "Hello $name"
}
It's more concise and makes the "functional style" more readable. Is this 
something Groovy users would appreciate?

Re: [RFE] Methods as expressions

[David Dawson]

I personally agree with Cedric, having the intent of "proper" functions
would be useful. Perhaps the = could be replaced, but I certainly like the
idea of having more expression oriented syntax in Groovy.

Java itself seems to be moving in this direction with the proposed switch
expression syntax?  This feels very similar?



On 20 March 2018 at 11:39, mg  wrote:

> @style rules: Then change your style rules to allow single line single
> statement blocks, do not change the language, no ?-)
>
>  Ursprüngliche Nachricht 
> Von: Cédric Champeau 
> Datum: 20.03.18 12:23 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: Re: [RFE] Methods as expressions
>
> Again that's a declaration of intent (if you put apart the fact that you
> can have style rules that force you to put the brackets on new lines).
>
> When I write:
>
> double surface(double x, double y) = x * y
>
> It's very clear what the intent of this is. It's an expression, a
> _function_. On the other hand, { ... } declares a block, that could
> represent an expression, or a statement, or a list of statements, one of
> them returning an expression. I like the declaration of intent.
>
> 2018-03-20 12:20 GMT+01:00 mg :
>
>> Am having a migraine right now so hard to concentrate / think straight
>> but it seems all that syntax does is getting rid of a single character ?
>>
>> Integer truth() { 42 }
>>
>> could then be written as
>>
>> Integer truth() = 42
>>
>>
>> or
>>
>> String hello(String name) { "Hello $name" }
>>
>> String hello(String name) = Hello $name"
>>
>> (why did you use a return keyword in your sample ?)
>>
>> I dont see an improvement in readability here - the main "advantage" is
>> that curly braces are annoying to input on non-US keyboard layouts ;-)
>>
>> mg
>>
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: Cédric Champeau 
>> Datum: 20.03.18 11:41 (GMT+01:00)
>> An: dev@groovy.apache.org
>> Betreff: [RFE] Methods as expressions
>>
>> Hi,
>>
>> One of the Kotlin features I really like is the short-hand notation for
>> simple expression methods:
>>
>> class Foo {
>> fun truth(): Integer = 42
>> }
>>
>> For example, in Groovy, you write:
>>
>> @Controller("/") class HelloController {
>>
>> @Get("/hello/{name}")
>> String hello(String name) {
>> return "Hello $name"
>> }
>> }
>>
>>
>> but we could write:
>>
>> @Controller("/")
>> class HelloController {
>> @Get("/hello/{name}")
>> String hello(String name) = "Hello $name"
>> }
>>
>>
>> It's more concise and makes the "functional style" more readable. Is this
>> something Groovy users would appreciate?
>>
>>
>

Re: [RFE] Methods as expressions

[mg]

@style rules: Then change your style rules to allow single line single 
statement blocks, do not change the language, no ?-)
 Ursprüngliche Nachricht Von: Cédric Champeau 
 Datum: 20.03.18  12:23  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: Re: [RFE] Methods as expressions 
Again that's a declaration of intent (if you put apart the fact that you can 
have style rules that force you to put the brackets on new lines).

When I write:

double surface(double x, double y) = x * y

It's very clear what the intent of this is. It's an expression, a _function_. 
On the other hand, { ... } declares a block, that could represent an 
expression, or a statement, or a list of statements, one of them returning an 
expression. I like the declaration of intent.

2018-03-20 12:20 GMT+01:00 mg :
Am having a migraine right now so hard to concentrate / think straight but it 
seems all that syntax does is getting rid of a single character ?
Integer truth() { 42 }
could then be written as
Integer truth() = 42

or
String hello(String name) { "Hello $name" }
String hello(String name) = Hello $name"
(why did you use a return keyword in your sample ?)
I dont see an improvement in readability here - the main "advantage" is that 
curly braces are annoying to input on non-US keyboard layouts ;-)
mg


 Ursprüngliche Nachricht Von: Cédric Champeau 
 Datum: 20.03.18  11:41  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: [RFE] Methods as expressions 
Hi,

One of the Kotlin features I really like is the short-hand notation for simple 
expression methods:

class Foo {
    fun truth(): Integer = 42
}

For example, in Groovy, you write:

@Controller("/") class HelloController {

@Get("/hello/{name}") 
String hello(String name) {
return "Hello $name"
}
}
but we could write:

@Controller("/") 
class HelloController {
@Get("/hello/{name}") 
String hello(String name) = "Hello $name"
}
It's more concise and makes the "functional style" more readable. Is this 
something Groovy users would appreciate?

Re: [RFE] Methods as expressions

[mg]

on the other hand assignment normally means "immediate evaluation" whereas 
block means "delayed evaluation", so you are sort of breaking with that...

 Ursprüngliche Nachricht Von: Cédric Champeau 
 Datum: 20.03.18  12:23  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: Re: [RFE] Methods as expressions 
Again that's a declaration of intent (if you put apart the fact that you can 
have style rules that force you to put the brackets on new lines).

When I write:

double surface(double x, double y) = x * y

It's very clear what the intent of this is. It's an expression, a _function_. 
On the other hand, { ... } declares a block, that could represent an 
expression, or a statement, or a list of statements, one of them returning an 
expression. I like the declaration of intent.

2018-03-20 12:20 GMT+01:00 mg :
Am having a migraine right now so hard to concentrate / think straight but it 
seems all that syntax does is getting rid of a single character ?
Integer truth() { 42 }
could then be written as
Integer truth() = 42

or
String hello(String name) { "Hello $name" }
String hello(String name) = Hello $name"
(why did you use a return keyword in your sample ?)
I dont see an improvement in readability here - the main "advantage" is that 
curly braces are annoying to input on non-US keyboard layouts ;-)
mg


 Ursprüngliche Nachricht Von: Cédric Champeau 
 Datum: 20.03.18  11:41  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: [RFE] Methods as expressions 
Hi,

One of the Kotlin features I really like is the short-hand notation for simple 
expression methods:

class Foo {
    fun truth(): Integer = 42
}

For example, in Groovy, you write:

@Controller("/") class HelloController {

@Get("/hello/{name}") 
String hello(String name) {
return "Hello $name"
}
}
but we could write:

@Controller("/") 
class HelloController {
@Get("/hello/{name}") 
String hello(String name) = "Hello $name"
}
It's more concise and makes the "functional style" more readable. Is this 
something Groovy users would appreciate?

Re: [RFE] Methods as expressions

[Paolo Di Tommaso]

I tend to agree. Also in Kotlin it tends a bit more readable because the
function return type is postponed.

IMO little is added by the proposed syntax extension.


p

On Tue, Mar 20, 2018 at 12:20 PM, mg  wrote:

> Am having a migraine right now so hard to concentrate / think straight but
> it seems all that syntax does is getting rid of a single character ?
>
> Integer truth() { 42 }
>
> could then be written as
>
> Integer truth() = 42
>
>
> or
>
> String hello(String name) { "Hello $name" }
>
> String hello(String name) = Hello $name"
>
> (why did you use a return keyword in your sample ?)
>
> I dont see an improvement in readability here - the main "advantage" is
> that curly braces are annoying to input on non-US keyboard layouts ;-)
>
> mg
>
>
>
>  Ursprüngliche Nachricht 
> Von: Cédric Champeau 
> Datum: 20.03.18 11:41 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: [RFE] Methods as expressions
>
> Hi,
>
> One of the Kotlin features I really like is the short-hand notation for
> simple expression methods:
>
> class Foo {
> fun truth(): Integer = 42
> }
>
> For example, in Groovy, you write:
>
> @Controller("/") class HelloController {
>
> @Get("/hello/{name}")
> String hello(String name) {
> return "Hello $name"
> }
> }
>
>
> but we could write:
>
> @Controller("/")
> class HelloController {
> @Get("/hello/{name}")
> String hello(String name) = "Hello $name"
> }
>
>
> It's more concise and makes the "functional style" more readable. Is this
> something Groovy users would appreciate?
>
>

Re: [RFE] Methods as expressions

[Cédric Champeau]

Again that's a declaration of intent (if you put apart the fact that you
can have style rules that force you to put the brackets on new lines).

When I write:

double surface(double x, double y) = x * y

It's very clear what the intent of this is. It's an expression, a
_function_. On the other hand, { ... } declares a block, that could
represent an expression, or a statement, or a list of statements, one of
them returning an expression. I like the declaration of intent.

2018-03-20 12:20 GMT+01:00 mg :

> Am having a migraine right now so hard to concentrate / think straight but
> it seems all that syntax does is getting rid of a single character ?
>
> Integer truth() { 42 }
>
> could then be written as
>
> Integer truth() = 42
>
>
> or
>
> String hello(String name) { "Hello $name" }
>
> String hello(String name) = Hello $name"
>
> (why did you use a return keyword in your sample ?)
>
> I dont see an improvement in readability here - the main "advantage" is
> that curly braces are annoying to input on non-US keyboard layouts ;-)
>
> mg
>
>
>
>  Ursprüngliche Nachricht 
> Von: Cédric Champeau 
> Datum: 20.03.18 11:41 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: [RFE] Methods as expressions
>
> Hi,
>
> One of the Kotlin features I really like is the short-hand notation for
> simple expression methods:
>
> class Foo {
> fun truth(): Integer = 42
> }
>
> For example, in Groovy, you write:
>
> @Controller("/") class HelloController {
>
> @Get("/hello/{name}")
> String hello(String name) {
> return "Hello $name"
> }
> }
>
>
> but we could write:
>
> @Controller("/")
> class HelloController {
> @Get("/hello/{name}")
> String hello(String name) = "Hello $name"
> }
>
>
> It's more concise and makes the "functional style" more readable. Is this
> something Groovy users would appreciate?
>
>

Re: [RFE] Methods as expressions

[mg]

PS: I am also worried that unecessarily deviating from Java syntax would make 
it harder for Java devs to pick up Groovy...

 Ursprüngliche Nachricht Von: Cédric Champeau 
 Datum: 20.03.18  11:41  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: [RFE] Methods as expressions 
Hi,

One of the Kotlin features I really like is the short-hand notation for simple 
expression methods:

class Foo {
    fun truth(): Integer = 42
}

For example, in Groovy, you write:

@Controller("/") class HelloController {

@Get("/hello/{name}") 
String hello(String name) {
return "Hello $name"
}
}
but we could write:

@Controller("/") 
class HelloController {
@Get("/hello/{name}") 
String hello(String name) = "Hello $name"
}
It's more concise and makes the "functional style" more readable. Is this 
something Groovy users would appreciate?

Re: [RFE] Methods as expressions

[mg]

Am having a migraine right now so hard to concentrate / think straight but it 
seems all that syntax does is getting rid of a single character ?
Integer truth() { 42 }
could then be written as
Integer truth() = 42

or
String hello(String name) { "Hello $name" }
String hello(String name) = Hello $name"
(why did you use a return keyword in your sample ?)
I dont see an improvement in readability here - the main "advantage" is that 
curly braces are annoying to input on non-US keyboard layouts ;-)
mg


 Ursprüngliche Nachricht Von: Cédric Champeau 
 Datum: 20.03.18  11:41  (GMT+01:00) An: 
dev@groovy.apache.org Betreff: [RFE] Methods as expressions 
Hi,

One of the Kotlin features I really like is the short-hand notation for simple 
expression methods:

class Foo {
    fun truth(): Integer = 42
}

For example, in Groovy, you write:

@Controller("/") class HelloController {

@Get("/hello/{name}") 
String hello(String name) {
return "Hello $name"
}
}
but we could write:

@Controller("/") 
class HelloController {
@Get("/hello/{name}") 
String hello(String name) = "Hello $name"
}
It's more concise and makes the "functional style" more readable. Is this 
something Groovy users would appreciate?

Re: [RFE] Methods as expressions

[Cédric Champeau]

I agree, that's the syntax I use for now. But I like the expression syntax
`=` because of the explicitness of the expression (it's a function which
value is ...). It's less about saving characters than it is about
expressing the intent.

2018-03-20 12:08 GMT+01:00 Andres Almiray :

> FYI you can also write it like
>
> @Controller("/") class HelloController {
> @Get("/hello/{name}")
> String hello(String name) { "Hello $name" }
> }
>
> So you're only saving 2 characters (space and closing brace) by following
> Kotlin/Scala syntax.
>
> Cheers,
> Andres
>
>
> ---
> Java Champion; Groovy Enthusiast
> JCP EC Associate Seat
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary,
> and those who don't.
> To understand recursion, we must first understand recursion.
>
> On Tue, Mar 20, 2018 at 11:41 AM, Cédric Champeau <
> cedric.champ...@gmail.com> wrote:
>
>> Hi,
>>
>> One of the Kotlin features I really like is the short-hand notation for
>> simple expression methods:
>>
>> class Foo {
>> fun truth(): Integer = 42
>> }
>>
>> For example, in Groovy, you write:
>>
>> @Controller("/") class HelloController {
>>
>> @Get("/hello/{name}")
>> String hello(String name) {
>> return "Hello $name"
>> }
>> }
>>
>>
>> but we could write:
>>
>> @Controller("/")
>> class HelloController {
>> @Get("/hello/{name}")
>> String hello(String name) = "Hello $name"
>> }
>>
>>
>> It's more concise and makes the "functional style" more readable. Is this
>> something Groovy users would appreciate?
>>
>>
>

Re: [RFE] Methods as expressions

[Andres Almiray]

FYI you can also write it like

@Controller("/") class HelloController {
@Get("/hello/{name}")
String hello(String name) { "Hello $name" }
}

So you're only saving 2 characters (space and closing brace) by following
Kotlin/Scala syntax.

Cheers,
Andres


---
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

On Tue, Mar 20, 2018 at 11:41 AM, Cédric Champeau  wrote:

> Hi,
>
> One of the Kotlin features I really like is the short-hand notation for
> simple expression methods:
>
> class Foo {
> fun truth(): Integer = 42
> }
>
> For example, in Groovy, you write:
>
> @Controller("/") class HelloController {
>
> @Get("/hello/{name}")
> String hello(String name) {
> return "Hello $name"
> }
> }
>
>
> but we could write:
>
> @Controller("/")
> class HelloController {
> @Get("/hello/{name}")
> String hello(String name) = "Hello $name"
> }
>
>
> It's more concise and makes the "functional style" more readable. Is this
> something Groovy users would appreciate?
>
>

Re: [RFE] Methods as expressions

[David Dawson]

Yes, I would love this kind of thing

On 20 March 2018 at 10:41, Cédric Champeau 
wrote:

> Hi,
>
> One of the Kotlin features I really like is the short-hand notation for
> simple expression methods:
>
> class Foo {
> fun truth(): Integer = 42
> }
>
> For example, in Groovy, you write:
>
> @Controller("/") class HelloController {
>
> @Get("/hello/{name}")
> String hello(String name) {
> return "Hello $name"
> }
> }
>
>
> but we could write:
>
> @Controller("/")
> class HelloController {
> @Get("/hello/{name}")
> String hello(String name) = "Hello $name"
> }
>
>
> It's more concise and makes the "functional style" more readable. Is this
> something Groovy users would appreciate?
>
>

[RFE] Methods as expressions

[Cédric Champeau]

Hi,

One of the Kotlin features I really like is the short-hand notation for
simple expression methods:

class Foo {
fun truth(): Integer = 42
}

For example, in Groovy, you write:

@Controller("/") class HelloController {

@Get("/hello/{name}")
String hello(String name) {
return "Hello $name"
}
}


but we could write:

@Controller("/")
class HelloController {
@Get("/hello/{name}")
String hello(String name) = "Hello $name"
}


It's more concise and makes the "functional style" more readable. Is this
something Groovy users would appreciate?