@Naveen: > If generator composition isn't directly supported somehow, then I'd have to > say I personally find the function composition proposal more compelling on > its own, even in the absence of a pipeline operator.
That’s all right, Naveen; thank you for reading the explainer and/or spec anyway. You may find the smart pipelines—or pipelines in general—still useful for all its other use cases, including method extraction, method application, function application, and partial application. And, importantly, the smart pipeline proposal does not preclude the future addition of a composition operator that can compose generators. It is just out of the current scope. I myself am trying to think of ways that smart pipelines might be eventually extended to support generator composition. As for TheNavigateur’s proposal in specifics, though—I will say that I think its approach to even generators has disadvantages, though I need to think more about someone might best address them. Perhaps most seriously, generators are not intended by the designers to be distinguishable from functions that return iterators (I think I can find a citation from Domenic Denicola for that), just like how async functions are not intended to be distinguishable from promise-returning functions (I’m almost certain can find a citation from Denicola for that). But in addition, the problem of plural/iterator/functor/whatever-type composition is not as easy as simply as treating generators and async generators with special behavior. There are so many types of plural or container objects—not only generators and async generators, but also maybes, streams, observables, and the iterators themselves. TheNavigateur’s approach does not address these, despite their being reasonable similar cases. And there are also many ways to compose them. TheNavigateur’s approach only addresses composition with mapping. But I would want a pipeline approach that addresses plural things to also be able to compose functions with flattened mapping, filtering, taking/dropping, partitioning, reduction, and so many other types of transformations. There is an alternative proposal for function composition, https://github.com/isiahmeadows/function-composition-proposal/blob/master/README.md, which tries another approach: having a well-known symbol Symbol.lift, which is used. But I’m not satisfied with that proposal either. I want to see if there is a different approach to try, one that may integrate with smart pipelines. Something like `generateRandomNumbers() |>> map f |>> filter g |>> take 5`…but I don’t yet know precisely how. But smart pipelines might be extendable to handle them. Either way, it can be dealt with later. There are many other benefits, as hopefully you can see from the real-world code examples. But we’ll see, once the Babel plugins are written and TC39 takes a look. Thanks for reading the explainer and/or spec. Warm re-gards, J. S. Choi _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
