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 to support multiple paradigms, but I feel this is trying to cater to the needs of concatenative / point-free style programming, in a language and environment which doesn't really have the functional compositionality to take advantage of it -- because Groovy is at its heart object-oriented. Your proposal is essentially the forward pipe operator |> for function composition, as seen in a number of functional languages, like F# and Elm (as "&" in Haskell). In those languages, it makes a lot of sense, since the function is the primarily compositional building block. In Groovy, it's the object, and many of the core features of Groovy (like overloading, extension methods, AST transformations, closures) are added to support those. In practice, I've seen very little Groovy code which ends up being formulated as baz(bar(foo(x))) -- but I've seen a lot of x.foo().bar().baz() instead. It's a better match, and Groovy already has a great operator "." to make programs easy to read and type -Jesper > On 25 Feb 2018, at 14.38, Daniel.Sun <[email protected]> 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 [1]): > w = x => foo => bar => baz > > Any thoughts? > > Cheers, > Daniel.Sun > [1] https://en.m.wikipedia.org/wiki/Concatenative_programming_language > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
