TheNavigateur / proposal-pipeline-operator-for-function-composition

+> for function composition
67 stars 2 forks source link

Cleanup + Show args in switchOnEngineThenDrive #2

Closed joshburgess closed 6 years ago

joshburgess commented 6 years ago

Just cleaned some things up with extra spacing in the arrow functions + tried to better show the composition in switchOnEngineThenDrive by showing how its arguments would get passed through.

TheNavigateur commented 6 years ago

The whole point of the switchOnEngineThenDrive example is to show how multiple no-args functions can be tersely chained to be executed one after the other in a composed function, by simply using +>. Your example in passing in an argument is the same as the doubleThenSquare example, so doesn't illustrate the point.

joshburgess commented 6 years ago

Ah, sorry. I misinterpreted the intent, I guess. I don't think that's a common use case, as functional pipelines are typically used to pass a value through a series of functions.

Do you think spacing out the arrow function examples would provide a bit cleaner syntax? I've never seen anyone write those without spaces before.

bathos commented 6 years ago

I would agree this isn’t a good illustration of use. It miscommunicates the relationship between the functions, has nothing to do with pipelining, and there’s even already an operator in the language that does this without these issues.

TheNavigateur commented 6 years ago

@bathos Which operator?

bathos commented 6 years ago

Comma is like semicolon within expressions:

const switchOnEngineThenDrive = () => (switchOnEngine(), drive());

Not that I’d particularly recommend it, but it’s less opaque about intention/relationship. With the example, somebody reading that code later won’t know whether drive actually takes an argument or not if one uses pipelining as shorthand for 'call in order' regardless of whether there’s anything "flowing through the pipe".

TheNavigateur commented 6 years ago

I would tend to use switchOnEngine +> drive because it's shorter, but I take your point. I'm guessing for those for whom this is a problem, I'm guessing it's only possible to enforce otherwise through TypeScript and a linter. I don't think even a JavaScript linter can necessarily enforce that the operands must take args, no matter how composition is to be implemented. I personally have no problem with it, since it's a left-to-right in-order composition, but at that point it becomes a matter of preference