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
