The following example code is a bit hard to read: const { status } = await send(capitalize(greeting) + "!") console.log(status) I disagree, I find this example code very easy to read because it reads like idiomatic Javascript. Unlike this library.
Show HN: A JavaScript function that looks and behaves like a pipe operator
21–30 of 148 posts
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#22This would be my preferred syntax: status = greeting+"!" ~> capitalize ~> send This would need 2 changes to JS: 1: ~> being a pipe operator 2: Calling an async function from within an async function implies await Without 2, it would look like this: status = greeting+"!" ~> capitalize ~> await send
Which is basically what the proposal is https://github.com/tc39/proposal-pipeline-operator#this-prop...
a = d(c(b,7))
into a = b |> c(%,7) |> d(%)
and I would like to see it turn into a = b,7 ~> c ~> dRe: Show HN: A JavaScript function that looks and behaves like a pipe operator
#23Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#24Looks tidier to my eyes
const newPipe = ppipe.extend({
divide (x, y) {
return x / y;
},
log(...params) {
console.log(...params);
return params[params.length - 1];
}
});
const res = await newPipe(10)
.pipe(x => x + 1)
.divide(_, 11)
.log("here is our x: ") //logs "here is our x: 1"
.pipe(x => x + 1) // 2Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#25 (-> x
(f)
(g)
(h))
https://clojure.org/guides/threading_macrosRe: Show HN: A JavaScript function that looks and behaves like a pipe operator
#26Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#27 pipe((p) => ([
"hello",
p.concat("!"),
send,
p.status,
console.log
]));
Where `p` stands for Proxy to the previous result. Under the hood it would just return an object describing the name of the called method and arguments passed.The pipe function would then iterate over the array, calling methods as described.
It's not immediately clear what should happen when a method's return type is a function, but I suppose this can be handled via convention.
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#28Honestly, if prototype pollution was not a problem for optimization and other things I’d just toss a Object.prototype.pipeTo = function(f) { return f(this) }; And call it a day. It does about 80% of what a pipe macro would do, has instant compatibility with other prototype methods and leads to very simple types. The only issue is that you have to define lambdas to call multivariable functions. D has got this very, ve…
Nowadays, as someone writing a library, you can work around prototype pollution via Symbols and let your users modify prototypes on their terms.
Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#29Earlier quoted context omitted.
Which is basically what the proposal is https://github.com/tc39/proposal-pipeline-operator#this-prop...
The difference is that they want to turn a = d(c(b,7)) into a = b |> c(%,7) |> d(%) and I would like to see it turn into a = b,7 ~> c ~> d
a = (b, 7) |> c(*%) |> d(%)
Too much operator soup I guess.Re: Show HN: A JavaScript function that looks and behaves like a pipe operator
#30The following example code is a bit hard to read: const { status } = await send(capitalize(greeting) + "!") console.log(status) I disagree, I find this example code very easy to read because it reads like idiomatic Javascript. Unlike this library.