You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Cédric Champeau <ce...@gmail.com> on 2018/03/20 10:41:34 UTC
[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
Posted by Daniel Sun <re...@hotmail.com>.
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
Re: [RFE] Methods as expressions
Posted by Jochen Theodorou <bl...@gmx.org>.
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 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
Posted by "Daniel.Sun" <su...@apache.org>.
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
Posted by Cédric Champeau <ce...@gmail.com>.
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 <aa...@gmail.com>:
> 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.champeau@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
Posted by Andres Almiray <aa...@gmail.com>.
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.champeau@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
Posted by David Dawson <da...@simplicityitself.com>.
Yes, I would love this kind of thing
On 20 March 2018 at 10:41, Cédric Champeau <ce...@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
Posted by Guillaume Laforge <gl...@gmail.com>.
Another case is a method / function that returns a closure, would we allow
the syntax:
def m(String x, int y) = { x * y }
?
On Wed, Mar 21, 2018 at 3:46 AM, Daniel Sun <re...@hotmail.com> wrote:
> 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
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [RFE] Methods as expressions
Posted by Daniel Sun <re...@hotmail.com>.
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: [RFE] Methods as expressions
Posted by Paolo Di Tommaso <pa...@gmail.com>.
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 <mg...@arscreat.com> 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 <ce...@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?
>
>
Re: [RFE] Methods as expressions
Posted by David Dawson <da...@simplicityitself.com>.
sorry, Result is an enum that "Ok" and "Err" are members of.
On 22 March 2018 at 00:18, MG <mg...@arscreat.com> wrote:
> Hi David,
>
> thank you for the Rust example. The "Ok" and "Err" are special constructs,
> right - interesting, though I am not convinced...
>
> Leaving Groovy loop constructs would be possible, if their closure
> argument would be inlined (same as a regular for or if block), which would
> support break/return/continue: https://issues.apache.org/
> jira/browse/GROOVY-8301 :-)
>
> Cheers,
> mg
>
>
>
> On 22.03.2018 00:06, David Dawson wrote:
>
> In rust, the generally promoted style is to not use returns if you can
> avoid it, and have the final expression in a particular block evaluated for
> the return.
>
> You can do returns in a flow control expression, in which case the
> surrounding block is returned (the function, say).
>
> From the rust docs, slightly cut down, ignore the lifetime gubbins. This
> parses a number from a string, if the parse fails, it returns Err, if it
> succeeds, it does a multiply and returns the value.
>
> fn multiply(first_number_str: &str) -> Result<i32, ParseIntError> {
> let first_number = match first_number_str.parse::<i32>() {
> Ok(first_number) => first_number,
> Err(e) => *return Err(e)*,
> };
>
> Ok(first_number * 5)
> }
>
> If the second branch in the match expression is invoked, the method will
> return. Otherwise, you get the Ok.
>
> I _*think*_ this feels natural, but I suspect thats more that I've just
> used it like this.
>
> That said, I have sometimes found myself reading the Groovy docs asking
> the question "how can I do an early punch out of this .each{}?"
>
>
> On 21 March 2018 at 21:47, MG <mg...@arscreat.com> wrote:
>
>> I am using the statically imported method
>>
>> static <T> T eval(final Closure<T> cls) { cls() }
>>
>> right now for this.
>>
>> This works well, and just has the performance drawback that it is based
>> on closures. Return here of course leaves the closure, so effectively
>> returns from the eval method.
>>
>> Should Groovy natively support if-expressions or something like this, the
>> return keyword is the big question mark here for me: Should it leave the
>> expression, or the surrounding method ?
>> Maybe if a construct is used as an expression, it should follow closure
>> semantics, and return should leave the expression, whereas otherwise (e.g.
>> for potential future "inline closures" not used as expressions, for
>> instance a SQL forEach loop construct) it should leave the surrounding
>> method ?
>>
>>
>>
>> On 21.03.2018 22:08, eric.milles@thomsonreuters.com wrote:
>>
>> I think you could experiment with this using a closure, since return
>> statements have this expression property already:
>>
>>
>>
>> final foo = ({ ->
>>
>> if(...) { ... }
>>
>> else if(...) { ... }
>>
>> else if(...) { ... }
>>
>> else { ... }
>>
>> }())
>>
>>
>>
>>
>>
>> *From:* mg [mailto:mgbiz@arscreat.com <mg...@arscreat.com>]
>> *Sent:* Wednesday, March 21, 2018 4:03 PM
>> *To:* dev@groovy.apache.org
>> *Subject:* Re: [RFE] Methods as expressions
>>
>>
>>
>> Having control flow statements as expressions in Groovy would feel pretty
>> natural to me. I had always assumed there were reasons why this was not
>> supported, so I did not bring it up...
>>
>> I currently use the simulated eval language extension I proposed for
>> that, i.e.
>>
>>
>>
>> final foo = eval {
>>
>> if(...) { ... }
>>
>> else if(...) { ... }
>>
>> else if(...) { ... }
>>
>> else { ... }
>>
>> }
>>
>>
>>
>> in cases where using "?" would be too complex.
>>
>>
>>
>> That uses a closure, of course, so not optimal for all applications.
>>
>>
>>
>> Question: Does a return-statement inside the if-expression leave the
>> expression, or the enclosing method in Rust ?
>>
>>
>>
>>
>>
>
>
Re: [RFE] Methods as expressions
Posted by MG <mg...@arscreat.com>.
Hi David,
thank you for the Rust example. The "Ok" and "Err" are special
constructs, right - interesting, though I am not convinced...
Leaving Groovy loop constructs would be possible, if their closure
argument would be inlined (same as a regular for or if block), which
would support break/return/continue:
https://issues.apache.org/jira/browse/GROOVY-8301 :-)
Cheers,
mg
On 22.03.2018 00:06, David Dawson wrote:
> In rust, the generally promoted style is to not use returns if you can
> avoid it, and have the final expression in a particular block
> evaluated for the return.
>
> You can do returns in a flow control expression, in which case the
> surrounding block is returned (the function, say).
>
> From the rust docs, slightly cut down, ignore the lifetime gubbins.
> This parses a number from a string, if the parse fails, it returns
> Err, if it succeeds, it does a multiply and returns the value.
>
> fn multiply(first_number_str: &str) -> Result<i32, ParseIntError> {
> let first_number = match first_number_str.parse::<i32>() {
> Ok(first_number) => first_number,
> Err(e) => *return Err(e)*,
> };
>
> Ok(first_number * 5)
> }
>
> If the second branch in the match expression is invoked, the method
> will return. Otherwise, you get the Ok.
>
> I _/think/_ this feels natural, but I suspect thats more that I've
> just used it like this.
>
> That said, I have sometimes found myself reading the Groovy docs
> asking the question "how can I do an early punch out of this .each{}?"
>
>
> On 21 March 2018 at 21:47, MG <mgbiz@arscreat.com
> <ma...@arscreat.com>> wrote:
>
> I am using the statically imported method
>
> static <T> T eval(final Closure<T> cls) { cls() }
>
> right now for this.
>
> This works well, and just has the performance drawback that it is
> based on closures. Return here of course leaves the closure, so
> effectively returns from the eval method.
>
> Should Groovy natively support if-expressions or something like
> this, the return keyword is the big question mark here for me:
> Should it leave the expression, or the surrounding method ?
> Maybe if a construct is used as an expression, it should follow
> closure semantics, and return should leave the expression, whereas
> otherwise (e.g. for potential future "inline closures" not used as
> expressions, for instance a SQL forEach loop construct) it should
> leave the surrounding method ?
>
>
>
> On 21.03.2018 22:08, eric.milles@thomsonreuters.com
> <ma...@thomsonreuters.com> wrote:
>>
>> I think you could experiment with this using a closure, since
>> return statements have this expression property already:
>>
>> final foo = ({ ->
>>
>> if(...) { ... }
>>
>> else if(...) { ... }
>>
>> else if(...) { ... }
>>
>> else { ... }
>>
>> }())
>>
>> *From:*mg [mailto:mgbiz@arscreat.com]
>> *Sent:* Wednesday, March 21, 2018 4:03 PM
>> *To:* dev@groovy.apache.org <ma...@groovy.apache.org>
>> *Subject:* Re: [RFE] Methods as expressions
>>
>> Having control flow statements as expressions in Groovy would
>> feel pretty natural to me. I had always assumed there were
>> reasons why this was not supported, so I did not bring it up...
>>
>> I currently use the simulated eval language extension I proposed
>> for that, i.e.
>>
>> final foo = eval {
>>
>> if(...) { ... }
>>
>> else if(...) { ... }
>>
>> else if(...) { ... }
>>
>> else { ... }
>>
>> }
>>
>> in cases where using "?" would be too complex.
>>
>> That uses a closure, of course, so not optimal for all applications.
>>
>> Question: Does a return-statement inside the if-expression leave
>> the expression, or the enclosing method in Rust ?
>>
>
>
Re: [RFE] Methods as expressions
Posted by David Dawson <da...@simplicityitself.com>.
In rust, the generally promoted style is to not use returns if you can
avoid it, and have the final expression in a particular block evaluated for
the return.
You can do returns in a flow control expression, in which case the
surrounding block is returned (the function, say).
From the rust docs, slightly cut down, ignore the lifetime gubbins. This
parses a number from a string, if the parse fails, it returns Err, if it
succeeds, it does a multiply and returns the value.
fn multiply(first_number_str: &str) -> Result<i32, ParseIntError> {
let first_number = match first_number_str.parse::<i32>() {
Ok(first_number) => first_number,
Err(e) => *return Err(e)*,
};
Ok(first_number * 5)
}
If the second branch in the match expression is invoked, the method will
return. Otherwise, you get the Ok.
I _*think*_ this feels natural, but I suspect thats more that I've just
used it like this.
That said, I have sometimes found myself reading the Groovy docs asking the
question "how can I do an early punch out of this .each{}?"
On 21 March 2018 at 21:47, MG <mg...@arscreat.com> wrote:
> I am using the statically imported method
>
> static <T> T eval(final Closure<T> cls) { cls() }
>
> right now for this.
>
> This works well, and just has the performance drawback that it is based on
> closures. Return here of course leaves the closure, so effectively returns
> from the eval method.
>
> Should Groovy natively support if-expressions or something like this, the
> return keyword is the big question mark here for me: Should it leave the
> expression, or the surrounding method ?
> Maybe if a construct is used as an expression, it should follow closure
> semantics, and return should leave the expression, whereas otherwise (e.g.
> for potential future "inline closures" not used as expressions, for
> instance a SQL forEach loop construct) it should leave the surrounding
> method ?
>
>
>
> On 21.03.2018 22:08, eric.milles@thomsonreuters.com wrote:
>
> I think you could experiment with this using a closure, since return
> statements have this expression property already:
>
>
>
> final foo = ({ ->
>
> if(...) { ... }
>
> else if(...) { ... }
>
> else if(...) { ... }
>
> else { ... }
>
> }())
>
>
>
>
>
> *From:* mg [mailto:mgbiz@arscreat.com <mg...@arscreat.com>]
> *Sent:* Wednesday, March 21, 2018 4:03 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: [RFE] Methods as expressions
>
>
>
> Having control flow statements as expressions in Groovy would feel pretty
> natural to me. I had always assumed there were reasons why this was not
> supported, so I did not bring it up...
>
> I currently use the simulated eval language extension I proposed for that,
> i.e.
>
>
>
> final foo = eval {
>
> if(...) { ... }
>
> else if(...) { ... }
>
> else if(...) { ... }
>
> else { ... }
>
> }
>
>
>
> in cases where using "?" would be too complex.
>
>
>
> That uses a closure, of course, so not optimal for all applications.
>
>
>
> Question: Does a return-statement inside the if-expression leave the
> expression, or the enclosing method in Rust ?
>
>
>
>
>
Re: [RFE] Methods as expressions
Posted by MG <mg...@arscreat.com>.
I am using the statically imported method
static <T> T eval(final Closure<T> cls) { cls() }
right now for this.
This works well, and just has the performance drawback that it is based
on closures. Return here of course leaves the closure, so effectively
returns from the eval method.
Should Groovy natively support if-expressions or something like this,
the return keyword is the big question mark here for me: Should it leave
the expression, or the surrounding method ?
Maybe if a construct is used as an expression, it should follow closure
semantics, and return should leave the expression, whereas otherwise
(e.g. for potential future "inline closures" not used as expressions,
for instance a SQL forEach loop construct) it should leave the
surrounding method ?
On 21.03.2018 22:08, eric.milles@thomsonreuters.com wrote:
>
> I think you could experiment with this using a closure, since return
> statements have this expression property already:
>
> final foo = ({ ->
>
> if(...) { ... }
>
> else if(...) { ... }
>
> else if(...) { ... }
>
> else { ... }
>
> }())
>
> *From:*mg [mailto:mgbiz@arscreat.com]
> *Sent:* Wednesday, March 21, 2018 4:03 PM
> *To:* dev@groovy.apache.org
> *Subject:* Re: [RFE] Methods as expressions
>
> Having control flow statements as expressions in Groovy would feel
> pretty natural to me. I had always assumed there were reasons why this
> was not supported, so I did not bring it up...
>
> I currently use the simulated eval language extension I proposed for
> that, i.e.
>
> final foo = eval {
>
> if(...) { ... }
>
> else if(...) { ... }
>
> else if(...) { ... }
>
> else { ... }
>
> }
>
> in cases where using "?" would be too complex.
>
> That uses a closure, of course, so not optimal for all applications.
>
> Question: Does a return-statement inside the if-expression leave the
> expression, or the enclosing method in Rust ?
>
RE: [RFE] Methods as expressions
Posted by er...@thomsonreuters.com.
I think you could experiment with this using a closure, since return statements have this expression property already:
final foo = ({ ->
if(...) { ... }
else if(...) { ... }
else if(...) { ... }
else { ... }
}())
From: mg [mailto:mgbiz@arscreat.com]
Sent: Wednesday, March 21, 2018 4:03 PM
To: dev@groovy.apache.org
Subject: Re: [RFE] Methods as expressions
Having control flow statements as expressions in Groovy would feel pretty natural to me. I had always assumed there were reasons why this was not supported, so I did not bring it up...
I currently use the simulated eval language extension I proposed for that, i.e.
final foo = eval {
if(...) { ... }
else if(...) { ... }
else if(...) { ... }
else { ... }
}
in cases where using "?" would be too complex.
That uses a closure, of course, so not optimal for all applications.
Question: Does a return-statement inside the if-expression leave the expression, or the enclosing method in Rust ?
Re: [RFE] Methods as expressions
Posted by mg <mg...@arscreat.com>.
Having control flow statements as expressions in Groovy would feel pretty natural to me. I had always assumed there were reasons why this was not supported, so I did not bring it up...I currently use the simulated eval language extension I proposed for that, i.e.
final foo = eval { if(...) { ... } else if(...) { ... } else if(...) { ... } else { ... }}
in cases where using "?" would be too complex.
That uses a closure, of course, so not optimal for all applications.
Question: Does a return-statement inside the if-expression leave the expression, or the enclosing method in Rust ?
Cheers,mg
-------- Ursprüngliche Nachricht --------Von: David Dawson <da...@simplicityitself.com> Datum: 21.03.18 10:07 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: [RFE] Methods as expressions
in Rust, control flow statements are expressions. Partly this was done to enable the lifetimes to be more concisely controlled, but its a nice structure.
If done in groovy, this would work (toy example, picking the right payment provider based on a property)
def provider = if(request.name == "paypal") {
paypal()
} else {
other()
}
rather than
def provider
if(request.name == "paypal") {
provider = paypal()
} else {
provider = other()
}
This very quickly becomes natural and makes a certain type of bug harder to make (assigning the wrong var in one of the branches)
When combined with the method expression syntax, maybe some expressionified version of the switch syntax (a match?)
class Payments {
Provider provider(request) = switch(request.name) {
case "paypal": paypal()
case "stripe": stripe()
default : fake()
}
}
def provider = new Payments().provider(myPaymentRequest)
// blah
On 21 March 2018 at 08:53, Jochen Theodorou <bl...@gmx.org> wrote:
Am 21.03.2018 um 09:27 schrieb Cédric Champeau:
[...]
In any case, I was doubtful as you are here before actually using it in Kotlin. After a few weeks, it became clear to me this syntax was both more concise and more self-explanatory.
For me {} was always very clear, for {} starts a new scope, it is a block, that can return something. I did never even once think about these as expressions. That is why I really not often speak about closure expressions, but about attached and open blocks or Closure. And in that matter:
double x
double y
double surface(double x, double y) = x * y
I find it very unclear if the x is the field/property x or the method parameter. That is because normally = does not create a new scope. And especially normally = does not allow referencing variables from the left side declaration. For example:
class X {
def foo = 1
def bar() {
def foo = foo*2
}}
This is allowed in Groovy and Java, because the semantics are very clear. Since = does not do a forward declaration the local variable foo is not defined on the RHS. Thus the foo on the RHS can only mean the property/field.
class X {
def foo = 1
def bar(foo) {
def foo = foo*2
}}
This is not allows, because the block already declares a foo and another local variable of the name foo is not allowed
class X {
def foo = 1
def bar(foo) {
def bar = foo*2
}}
This is allowed and again the semantics are clear, because the parameter is a local scope that shadows the class scope, thus in the declaration of bar the foo in RHS means the foo from the method parameter.
double surface(double x, double y) = x * y
breaks with the former declaration and scoping logic. You can try rescue this by saying the = in the method declaration has nothing to do with the = in a declaration or assignment otherwise. But if I always have to do the expansion to the other version to understand what happens, then it is not easier for me.
On top of that I am a real bad fit for this style, because except for demo purposes I rarely write methods that contains only a single line of code. Maybe you could show real world examples that show the real coolness of this?
bye Jochen
Re: [RFE] Methods as expressions
Posted by David Dawson <da...@simplicityitself.com>.
in Rust, control flow statements are expressions. Partly this was done to
enable the lifetimes to be more concisely controlled, but its a nice
structure.
If done in groovy, this would work (toy example, picking the right payment
provider based on a property)
def provider = if(request.name == "paypal") {
paypal()
} else {
other()
}
rather than
def provider
if(request.name == "paypal") {
provider = paypal()
} else {
provider = other()
}
This very quickly becomes natural and makes a certain type of bug harder to
make (assigning the wrong var in one of the branches)
When combined with the method expression syntax, maybe some expressionified
version of the switch syntax (a match?)
class Payments {
Provider provider(request) = switch(request.name) {
case "paypal": paypal()
case "stripe": stripe()
default : fake()
}
}
def provider = new Payments().provider(myPaymentRequest)
// blah
On 21 March 2018 at 08:53, Jochen Theodorou <bl...@gmx.org> wrote:
>
>
> Am 21.03.2018 um 09:27 schrieb Cédric Champeau:
> [...]
>
>> In any case, I was doubtful as you are here before actually using it in
>> Kotlin. After a few weeks, it became clear to me this syntax was both more
>> concise and more self-explanatory.
>>
>
> For me {} was always very clear, for {} starts a new scope, it is a block,
> that can return something. I did never even once think about these as
> expressions. That is why I really not often speak about closure
> expressions, but about attached and open blocks or Closure. And in that
> matter:
>
> double x
> double y
> double surface(double x, double y) = x * y
>
> I find it very unclear if the x is the field/property x or the method
> parameter. That is because normally = does not create a new scope. And
> especially normally = does not allow referencing variables from the left
> side declaration. For example:
>
> class X {
> def foo = 1
> def bar() {
> def foo = foo*2
> }}
>
> This is allowed in Groovy and Java, because the semantics are very clear.
> Since = does not do a forward declaration the local variable foo is not
> defined on the RHS. Thus the foo on the RHS can only mean the
> property/field.
>
> class X {
> def foo = 1
> def bar(foo) {
> def foo = foo*2
> }}
>
> This is not allows, because the block already declares a foo and another
> local variable of the name foo is not allowed
>
> class X {
> def foo = 1
> def bar(foo) {
> def bar = foo*2
> }}
>
> This is allowed and again the semantics are clear, because the parameter
> is a local scope that shadows the class scope, thus in the declaration of
> bar the foo in RHS means the foo from the method parameter.
>
> double surface(double x, double y) = x * y
>
> breaks with the former declaration and scoping logic. You can try rescue
> this by saying the = in the method declaration has nothing to do with the =
> in a declaration or assignment otherwise. But if I always have to do the
> expansion to the other version to understand what happens, then it is not
> easier for me.
>
> On top of that I am a real bad fit for this style, because except for demo
> purposes I rarely write methods that contains only a single line of code.
> Maybe you could show real world examples that show the real coolness of
> this?
>
> bye Jochen
>
>
>
Re: [RFE] Methods as expressions
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 21.03.2018 um 09:27 schrieb Cédric Champeau:
[...]
> In any case, I was doubtful as you are here before actually using it in
> Kotlin. After a few weeks, it became clear to me this syntax was both
> more concise and more self-explanatory.
For me {} was always very clear, for {} starts a new scope, it is a
block, that can return something. I did never even once think about
these as expressions. That is why I really not often speak about closure
expressions, but about attached and open blocks or Closure. And in that
matter:
double x
double y
double surface(double x, double y) = x * y
I find it very unclear if the x is the field/property x or the method
parameter. That is because normally = does not create a new scope. And
especially normally = does not allow referencing variables from the left
side declaration. For example:
class X {
def foo = 1
def bar() {
def foo = foo*2
}}
This is allowed in Groovy and Java, because the semantics are very
clear. Since = does not do a forward declaration the local variable foo
is not defined on the RHS. Thus the foo on the RHS can only mean the
property/field.
class X {
def foo = 1
def bar(foo) {
def foo = foo*2
}}
This is not allows, because the block already declares a foo and another
local variable of the name foo is not allowed
class X {
def foo = 1
def bar(foo) {
def bar = foo*2
}}
This is allowed and again the semantics are clear, because the parameter
is a local scope that shadows the class scope, thus in the declaration
of bar the foo in RHS means the foo from the method parameter.
double surface(double x, double y) = x * y
breaks with the former declaration and scoping logic. You can try rescue
this by saying the = in the method declaration has nothing to do with
the = in a declaration or assignment otherwise. But if I always have to
do the expansion to the other version to understand what happens, then
it is not easier for me.
On top of that I am a real bad fit for this style, because except for
demo purposes I rarely write methods that contains only a single line of
code. Maybe you could show real world examples that show the real
coolness of this?
bye Jochen
Re: [RFE] Methods as expressions
Posted by Cédric Champeau <ce...@gmail.com>.
It's funny to see arguments about compatibility with Java here. Groovy's
compatibility with Java is the promise that you can _almost_ copy and paste
Java code and it compiles in Groovy. Not the other way around ;)
In any case, I was doubtful as you are here before actually using it in
Kotlin. After a few weeks, it became clear to me this syntax was both more
concise and more self-explanatory.
2018-03-21 9:07 GMT+01:00 David Dawson <da...@simplicityitself.com>:
> LOL. thanks, I probably deserved that being thrown back at me :-)
>
> I think that Jochen said it best "It seemed to be part of a bigger
> picture, but the bigger picture is missing."
>
> My CS background is on the weaker side, so I can't quite say what I want...
>
> Apart from Groovy, the two languages that I've *enjoyed* working with
> over the past few years are Clojure and Rust. Of the things in them, "code
> as data" and pure functions from clojure and heavier expression usage in
> Rust (of course, the actual advanced thing in Rust, lifetimes, aren't
> applicable at all to the JVM) are what I miss from them in Groovy. Still,
> Groovy does dominate my development when I have much choice in client
> projects.
>
> Echoing Jochen though, perhaps asking Cedric and Daniel, are these syntax
> suggestions picking around anything deeper? I'd love there to be, in
> Groovy 4 or whatever.
>
> David.
>
>
> On 20 March 2018 at 23:16, MG <mg...@arscreat.com> wrote:
>
>>
>>
>> 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_langu
>> age)). 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
Posted by David Dawson <da...@simplicityitself.com>.
LOL. thanks, I probably deserved that being thrown back at me :-)
I think that Jochen said it best "It seemed to be part of a bigger picture,
but the bigger picture is missing."
My CS background is on the weaker side, so I can't quite say what I want...
Apart from Groovy, the two languages that I've *enjoyed* working with over
the past few years are Clojure and Rust. Of the things in them, "code as
data" and pure functions from clojure and heavier expression usage in Rust
(of course, the actual advanced thing in Rust, lifetimes, aren't applicable
at all to the JVM) are what I miss from them in Groovy. Still, Groovy does
dominate my development when I have much choice in client projects.
Echoing Jochen though, perhaps asking Cedric and Daniel, are these syntax
suggestions picking around anything deeper? I'd love there to be, in
Groovy 4 or whatever.
David.
On 20 March 2018 at 23:16, MG <mg...@arscreat.com> wrote:
>
>
> 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_langu
> age)). 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
Posted by MG <mg...@arscreat.com>.
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
Posted by David Dawson <da...@simplicityitself.com>.
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, <er...@thomsonreuters.com> 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:mgbiz@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 <da...@simplicityitself.com>
>
> 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 <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 <ce...@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 <ce...@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?
>
>
>
>
>
Re: [RFE] Methods as expressions
Posted by MG <mg...@arscreat.com>.
On 20.03.2018 16:19, eric.milles@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: [RFE] Methods as expressions
Posted by er...@thomsonreuters.com.
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:mgbiz@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 <da...@simplicityitself.com>>
Datum: 20.03.18 13:00 (GMT+01:00)
An: dev@groovy.apache.org<ma...@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>> 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 <ce...@gmail.com>>
Datum: 20.03.18 12:23 (GMT+01:00)
An: dev@groovy.apache.org<ma...@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 <ce...@gmail.com>>
Datum: 20.03.18 11:41 (GMT+01:00)
An: dev@groovy.apache.org<ma...@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
Posted by mg <mg...@arscreat.com>.
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 <da...@simplicityitself.com> 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 <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 <ce...@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 <ce...@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?
Re: [RFE] Methods as expressions
Posted by David Dawson <da...@simplicityitself.com>.
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> 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 <ce...@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 <ce...@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?
>>
>>
>
Re: [RFE] Methods as expressions
Posted by mg <mg...@arscreat.com>.
@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 <ce...@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 <ce...@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?
Re: [RFE] Methods as expressions
Posted by mg <mg...@arscreat.com>.
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 <ce...@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 <ce...@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?
Re: [RFE] Methods as expressions
Posted by Cédric Champeau <ce...@gmail.com>.
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 <ce...@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?
>
>
Re: [RFE] Methods as expressions
Posted by mg <mg...@arscreat.com>.
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 <ce...@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?
Re: [RFE] Methods as expressions
Posted by 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 <ce...@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?