groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Dawson <david.daw...@simplicityitself.com>
Subject Re: [RFE] Methods as expressions
Date Tue, 20 Mar 2018 16:16:33 GMT
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, <eric.milles@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 <david.dawson@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 <mgbiz@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.champeau@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 <mgbiz@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.champeau@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?
>
>
>
>
>

Mime
View raw message