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 
<cedric.champ...@gmail.com> 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 <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> 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?




Reply via email to