Re: Java raw string literals

I may agree that double back-tick is not nice, however the rationale of this choice is that this syntax is meant to enable *raw* string literals i.e. a string for which is not required to escape the content of *any* character. In this context it makes sense. They are created exactly how they are ty

[GEP] Concatenative Method Calls

Hi all, I propose to introduce Concatenative Method Calls to Groovy. It can make code more readable, for example: Currently we write method calls like: y = foo(x) z = bar(y) w = baz(z) OR w = baz(bar(foo(x))) Concatenative Method Calls(inspired by [1]): w = x => foo => bar => baz Any

Re: [GEP] Concatenative Method Calls

I actually find that less readable, and feel like it would get even worse with multiple parameters. I’m not sure I see what the value here would be. A. On Sun, Feb 25, 2018 at 8:39 AM Daniel.Sun wrote: > Hi all, > > I propose to introduce Concatenative Method Calls to Groovy. It can > make

Re: [GEP] Concatenative Method Calls

Hi Daniel, I agree with Andrew, the example to me looks less readable. Do you have another example that shows what application you had in mind ? Cheers,mg Ursprüngliche Nachricht Von: Andrew Bayer Datum: 25.02.18 15:02 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: [GEP]

Re: [GEP] Concatenative Method Calls

Intuitively the => arrow-operators point in the wrong direction, since I feel foo gets applied to x, etc... How would additional arguments to an intermediate function be handled in this syntax ? Ursprüngliche Nachricht Von: "Daniel.Sun" Datum: 25.02.18 14:38 (GMT+01:00) An: d

Re: [GEP] Concatenative Method Calls

Intuitively the => arrow-operators point in the wrong direction, since I feel foo gets applied to x, etc... How would additional arguments to an intermediate function be handled in this syntax ? Ursprüngliche Nachricht Von: "Daniel.Sun" Datum: 25.02.18 14:38 (GMT+01:00) An: d

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: [GEP] Concatenative Method Calls

Interesting proposal and discussion! As somebody who routinely work in both Java, Groovy, TypeScript/ES6 and C#, I find this syntactically too close too arrow functions/lambdas, in other words, they may confuse a lot of readers. As for the semantic content: I realize that Groovy goes a long way

Re: [GEP] Concatenative Method Calls

Quick note in the discussion: we have already a form of composition with closures, using the right shift operator: http://mrhaki.blogspot.fr/2011/04/groovy-goodness-chain-closures-together.html?m=1 Le dim. 25 févr. 2018 à 16:02, Jesper Steen Møller a écrit : > Interesting proposal and discussio

Re: [GEP] Concatenative Method Calls

Hi Guillaume, I have to admit closure is very versatile... In practice, chained closures are a bit verbose :-( (obj1.&m1 >> obj2.&m2 >> obj3.&m3)(someParam) In addition, chained closures seems not to support multiple parameters. While I propose the following syntax to support mul

Re: [GEP] Concatenative Method Calls

On 25.02.2018 14:38, Daniel.Sun wrote: Hi all, I propose to introduce Concatenative Method Calls to Groovy. It can make code more readable, for example: Currently we write method calls like: y = foo(x) z = bar(y) w = baz(z) OR w = baz(bar(foo(x))) Concatenative Method Calls(inspired by [

Re: [GEP] Concatenative Method Calls

Hi Jochen, To be honest, I have no complex examples in my mind. Maybe it will be good for DSL(We can think `|>` as a big arrow drawn by | and >): ``` clothes |> clean |> dry |> notify ``` I ran the code you provided, error occurred as you expected, but we wish it could run well.