groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: [RFE] Methods as expressions
Date Tue, 20 Mar 2018 15:19:27 GMT
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
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 []
Sent: Tuesday, March 20, 2018 7:11 AM
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)
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 <<>>
@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)
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


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 ;-)


-------- Ursprüngliche Nachricht --------
Von: Cédric Champeau <<>>
Datum: 20.03.18 11:41 (GMT+01:00)
Betreff: [RFE] Methods as expressions

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

class Foo {
    fun truth(): Integer = 42

For example, in Groovy, you write:

@Controller("/") class HelloController {

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

but we could write:

class HelloController {
    String hello(String name) = "Hello $name"

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

View raw message