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 CliBuil
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 fo
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
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
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(..)
```
Cheer
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
defa
Hi Jochen,
I agree with you. We all want Groovy become groovier and groovier, but
we have not a big picture for the time being(e.g. no grammar evolving plan,
etc.)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
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 li
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 bra
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
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 h
+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]
*
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 he
I think my issue with this is similar to the problem I had recently with
something Daniel suggested: It seemed to be part of a bigger picture,
but the bigger picture is missing.
Am 20.03.2018 um 11:41 schrieb Cédric Champeau:
Hi,
One of the Kotlin features I really like is the short-hand nota
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
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.
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
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
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?
@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
Agai
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] M
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 see
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
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
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 $na
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 al
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
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:
>
> @Co
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) {
retur
29 matches
Mail list logo
