New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functions should work without chaining #31
Comments
I like the idea of no longer mixing in to underscore. At first I thought the use case of jumping between arrays/streams would be more common (hence the mixing in to underscore), but that hasn't been the case. I also like the idea of simplifying the input of understream to only readable streams and moving array->stream conversions to some other lib. As for how it's imported I'm partial to |
I actually considered removing the underscore-mixing requirement of understream in #29, since it seemed related. I can add that in now (in a way that's still backwards compatible) since that PR isn't merged yet? It's basically going involve having |
A comment from @jonahkagan that it's good to merge |
@jonahkagan doesn't this syntax:
also mean we'd need an explicit |
I think this is going to be a pretty breaking change. |
Is there something wrong with that? |
No. |
In the spirit of being more like Underscore, chaining should be optional syntax. Understream functions should stand alone, taking a (Readable) stream as an explicit first argument.
Chaining can be a clunky syntax when only one or two transformations will be applied. Furthermore, it implies that pipelines should be linear, which does not necessarily gel with the actual operations (like
join
or its inverse,partition
).For example, instead of writing this:
I should be able to write:
and get back a Readable stream in which some_fun is applied to each chunk.
Since this creates a name clash, I think mixing into Underscore should be dropped in favor of a new Understream variable. Some ideas:
_s
,us
,understream
,_stream
.The text was updated successfully, but these errors were encountered: