111–120 of 148 posts
I like goofy projects like this one but I think that if you insist on having calls there, then might as well make it more explicit with something like this: 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 it…
Reminds me of something I tried hacking together in python for fun from functools import partial class Pipeable: def __init__(self, fn): self.fn = fn def __ror__(self, lhs): return self.fn(lhs) def pipeable(fn): return lambda *args: Pipeable(partial(fn, *args)) filter = pipeable(filter) map = pipeable(map) list = pipeable(list) sum = pipeable(sum) min = pipeable(min) max = pipeable(max) any = pipeable(any) # Usage: r…
I like goofy projects like this one but I think that if you insist on having calls there, then might as well make it more explicit with something like this: 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 it…
Here's a very basic implementation: https://github.com/Tade0/pipe/blob/master/pipe-sync.js
pipeSync(p => [
"hello",
p + " world",
console.log
]);And then, remembering that everything has already been invented, I found this:
https://github.com/elixirscript/elixirscript
You're welcome.
Earlier quoted context omitted.
Tell that to Unix/FP lovers.
hahaha i mean this implementation. piping things in the shell is great
>The following example code is a bit hard to read: >const { status } = await send(capitalize(greeting) + "!") >console.log(status) No it's not hard to read. >Make it less nested, more vertical, by using the V "pipe": >V( greeting, // initial value "hi" >V (capitalize), // custom function call "Hi" >V .concat("!"), // String method `concat` call "Hi!" >V (send), // custom async function call Promise { } >V .status, //…
Someone decided to create a solution and then started looking for problems that will fit it. Finding none, they invented one.
I like goofy projects like this one but I think that if you insist on having calls there, then might as well make it more explicit with something like this: 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 it…
gulp.src(config.src)
.pipe(uglify())
.pipe(gulp.dest(config.dest))
.pipe(size());
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.
I think the implication is that it's difficult to read because it's read non-linearly. You first need to start in the middle at `greeting`, then work your way out to `capitalize` on the left, then to `+ "!"` on the right, then work your way out one more layer to the left with `send`. Some kind of pipe operator can make this easier to read by arranging the operations linearly from left to right (or top to bottom as is…
Sure, it is good most of the time, but operator precedence rules exist for a reason.
I don't want to read
2.chain(x => x * 2).chain(f)
f(2*x)
They can also be a distraction.
E.g. the library introduces its own promise-unwrapping semantics and more.
I don't see the use for such a generic implementation, although I applaud the effort.
Same thing. Less code, standard functions.