Await/ async?

Hi, I do a load of async programming, in the JVM world, mostly using RxJava and CompleteableFuture). Not so much GPars or Reactor these days, but the principles are fairly portable. I've noticed that since I started using typescript on the front end, getting access to await/ async there has been

Re: [RFE] Methods as expressions

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

Re: [RFE] Methods as expressions

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,

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 == "pay

Re: [RFE] Methods as expressions

whatever. David. On 20 March 2018 at 23:16, MG 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"],

Re: [RFE] Methods as expressions

> 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 > > > &

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?

Re: [RFE] Methods as expressions

Yes, I would love this kind of thing On 20 March 2018 at 10:41, Cédric Champeau 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: > > @Co

Re: [GEP] Concatenative Method Calls

Hello. I conceptually like this a lot, its a very dataflow style approach to the problem Conceptually, its similar to [1,2,3].map { it * 2 }.each { println it } Or in a unix shell cat file | grep x | echo Or perhaps something more reactive streams ish. In any case, its re-arranging the funct

Re: About if statement in the right hand of assignment statement

Hi Daniel, I would suggest that there are existing edge cases that also look very ugly. I could write if ( x == "hello" ? [] : false) { } and so on and get some very odd looking behaviour. Expression based flow control has some fascinating use cases, and I think it would be of great value to at

Re: About if statement in the right hand of assignment statement

I would very much appreciate this. I've been doing a chunk of work in Rust lately and it has the philosophy of "everything is an expression". It leads to things like this def val = if (something) { "hello" } else { "other stuff" } being very normal, which helps with a fair few constructs. Speci

Re: 答复: About the "implies" operator(GROOVY-2576)

;> here. >>>> NAML >>>> <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>>> >>>> -- >>>> View this message in context: Re: About the "implies" >>>> operator(GROOVY-2576) >>>> <http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738043.html> >>>> >>>> Sent from the Groovy Dev mailing list archive >>>> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at >>>> Nabble.com. >>>> >>>> >>>> >>>> -- >>>> If you reply to this email, your message will be added to the >>>> discussion below: >>>> http://groovy.329449.n5.nabble.com/About-the-implies-operato >>>> r-GROOVY-2576-tp5738035p5738104.html >>>> To unsubscribe from About the "implies" operator(GROOVY-2576), click >>>> here. >>>> NAML >>>> <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>>> >>>> -- >>>> View this message in context: 答复: About the "implies" >>>> operator(GROOVY-2576) >>>> <http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738105.html> >>>> >>>> Sent from the Groovy Dev mailing list archive >>>> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at >>>> Nabble.com. >>>> >>> >>> >> >> >> -- >> 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> >> >> > -- David Dawson | CEO | Simplicity Itself Tel +44 7866 011 256 Skype: davidadawson david.daw...@simplicityitself.com http://www.simplicityitself.com