Hi Jochen,
I submitted a JIRA ticket to show the evolving process :-)
https://issues.apache.org/jira/browse/GROOVY-8997
Cheers,
Daniel.Sun
-
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f3729
On 26.02.2018 00:53, Daniel Sun wrote:
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
```
In my experience the less grammar elements a DSL has t
As somebody who routinely works with Groovy ( ;-) ) I agree with all of
that.
Using e.g. |> instead of => seems to me a much better choice, for a
multitude of reasons.
While I personally do not have big need for such an operator, and am
generally a fan of using fluent method chaining (when I d
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.
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 [
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
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
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
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
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
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
] 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
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
13 matches
Mail list logo
