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
<david.daw...@simplicityitself.com<mailto:david.daw...@simplicityitself.com>>
Datum: 20.03.18 13:00 (GMT+01:00)
An: dev@groovy.apache.org<mailto: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 <mg...@arscreat.com<mailto:mg...@arscreat.com>>
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
<cedric.champ...@gmail.com<mailto:cedric.champ...@gmail.com>>
Datum: 20.03.18 12:23 (GMT+01:00)
An: dev@groovy.apache.org<mailto: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 <mg...@arscreat.com<mailto:mg...@arscreat.com>>:
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
<cedric.champ...@gmail.com<mailto:cedric.champ...@gmail.com>>
Datum: 20.03.18 11:41 (GMT+01:00)
An: dev@groovy.apache.org<mailto: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?
