Oh please, This is an alternative syntax that's very useful for many people. If you want too simplify syntax yourself you can use a linter to disable alternatives.
On Mar 10, 2018 22:56, "kai zhu" <[email protected]> wrote: > my vote is for neither. exactly what industry painpoint or > problem-space do either of these proposals solve? > > rather, they compound an existing industry painpoint; where > ocd-programmers have problems in deciding-and-choosing which es6 > style/design-pattern to employ and stick with before coding even > begins. many of us wish there were less choices, like python (and a > more assertive tc39 that makes clear certain proposals are > productivity-negative and not open for debate) so we could get on with > the actual coding-part. > > from a senior-engineer / technical-manager perspective, it also > doesn't help in managing an entire web-project; comprised of dozens of > sub-components that you didn't all write yourself; and having to > context-switch for each sub-component's quirky es6/es7/es8/es9 > style-guide/design-pattern. > > On 3/4/18, Isiah Meadows <[email protected]> wrote: > > Just thought I'd point out that the proposal itself entertains the > > possibility of a corresponding composition proposal [1]. Also, in my > > proposal, one of my "potential expansions" [2] would open a generic > > door for "lifting" over a type, addressing the concern of > > extensibility. (It's not ideal, and I just filed an issue in my repo > > for that, but that's orthogonal.) > > > > [1]: https://github.com/tc39/proposal-pipeline-operator# > related-proposals > > [2]: > > https://github.com/isiahmeadows/function-composition-proposal#possible- > expansions > > > > ----- > > > > Isiah Meadows > > [email protected] > > > > Looking for web consulting? Or a new website? > > Send me an email and we can get started. > > www.isiahmeadows.com > > > > > > On Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[email protected]> > > wrote: > >> Although it doesn't allow composition with generator functions like the > >> composition proposal does, otherwise it's a pretty good solution. > >> > >> My only concern with pipeline is that since it offers a different way of > >> calling functions than the `()` syntax, it can lead to mixed and hence > >> slightly more confusing code when both `()` and `|>` are used. For > example > >> multi arg and no-arg functions would still use `()`, and single arg > >> functions may or may not use `|>` depending on whether or not they may > >> prospectively use a pipeline. The composition operator doesn't supersede > >> the > >> `()` syntax in any context, and so it could be argued it would lead to > >> more > >> consistent, more readable code. > >> > >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[email protected]> > wrote: > >>> > >>> I'd like to point out the partial application operator: > >>> https://github.com/tc39/proposal-partial-application > >>> > >>> Sounds like the combination of pipeline + partial application would > >>> result > >>> in what is essentially the same as function composition operator: > >>> > >>> ``` > >>> const h = ? |> f |> g; > >>> ``` > >>> > >>> Which results in `h` being the composition `g • f`. > >>> > >>> > >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[email protected]> wrote: > >>> > >>> That could be a problem for readability. > >>> I agree with the rest of what you said. > >>> > >>> > >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall < > [email protected]> > >>> wrote: > >>>> > >>>> I don’t know the implications but I could easily imagine the pipeline > >>>> proposal being extended to not taking any input on the left hand side > >>>> and > >>>> effectively represent composition in the opposite direction. > >>>> > >>>> For example: > >>>> ``` > >>>> let h = |> f |> g > >>>> h(2) //g(f(2)) > >>>> ``` > >>>> > >>>> That said, the point holds for the proposal in its current state. > Being > >>>> able to compose functions > >>>> leads to much more expressivity than if you have > >>>> to call the pipeline (and collapse) where it is defined. > >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[email protected]>: > >>>>> > >>>>> The function composition operator composes function pipelines into > >>>>> functions for later use and/or further composition. Those functions > >>>>> still > >>>>> need to be called via the existing `()` syntax, so it doesn't offer a > >>>>> different way of calling functions as such. > >>>>> > >>>>> The function pipeline operator calls the function pipeline > immediately, > >>>>> so it is really only a different way of calling functions. > >>>>> > >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[email protected]> > wrote: > >>>>>> > >>>>>> How is either operator not "a different way of calling functions"? > >>>>>> > >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla < > [email protected]> > >>>>>> wrote: > >>>>>>> > >>>>>>> I was just thinking about the relative merits and coexistence (or > >>>>>>> not) > >>>>>>> of function composition operator and function pipeline operator > >>>>>>> features: > >>>>>>> > >>>>>>> e.g. > >>>>>>> > >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for- > function-composition > >>>>>>> https://github.com/tc39/proposal-pipeline-operator > >>>>>>> > >>>>>>> They can of course co-exist, but there is overlap only in the > respect > >>>>>>> that both allow function pipelines to be called from left to right > >>>>>>> (except > >>>>>>> the input parameter in the case of the composition feature, which > >>>>>>> requires > >>>>>>> existing bracket syntax to be used to call it). If one were to be > >>>>>>> chosen, > >>>>>>> would say that a function composition operator adds a whole new > >>>>>>> dimension of > >>>>>>> expressive power to the language, whereas a pipeline operator only > >>>>>>> offers a > >>>>>>> different way of calling functions. > >>>>>>> > >>>>>>> I was wondering about all of your thoughts about whether you'd > prefer > >>>>>>> only the pipeline operator, only the composition operator, or both, > >>>>>>> or > >>>>>>> neither to be added to the language (these are pretty much all the > >>>>>>> possibilities), and why. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> es-discuss mailing list > >>>>>>> [email protected] > >>>>>>> https://mail.mozilla.org/listinfo/es-discuss > >>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> es-discuss mailing list > >>>>> [email protected] > >>>>> https://mail.mozilla.org/listinfo/es-discuss > >>> > >>> > >>> _______________________________________________ > >>> es-discuss mailing list > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/es-discuss > >>> > >>> > >>> _______________________________________________ > >>> es-discuss mailing list > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
