-
Notifications
You must be signed in to change notification settings - Fork 49
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
Improve API of Streams #679
Comments
💎 $500 bounty • Kaizen SolutionsSteps to solve:
Thank you for contributing to getkyo/kyo! Add a bounty • Share on socials
|
Can you please clarify what the acceptance criteria are? I would like to /attempt #679 Options |
/attempt #679
|
Given my experience of having used FS2 Streams & ZIO Streams which are pull-based solutions. I would love to see the following, @hearnadam & @fwbrasil please feel free to add or subtract since you folks have way more expertise:
|
I'd suggest adding a |
- stop using class member, enforcing accidental eagerness - add new method: Stream.range to simplify creation of streams - init/range: accept `chunkSize` to limit size of Chunks- Chunk.from (Array): remove AnyRef type bound The first PR to address #679. This change is important to ensure the laziness of streams initialized from non-effectful sources.
PR 2 for #679 Rechunk was a bit tricky to implement as the remaining 'buffer' would get dropped unless the chunks perfectly aligned with the number of emits. Because of this, it's necessary to Emit a final empty chunk to ensure the buffer is flushed. This can sometimes drop the number of elements in a given chunk if a user Emits an empty chunk, but that shouldn't be a problem. --------- Co-authored-by: Flavio Brasil <fwbrasil@users.noreply.github.com>
The current API of streams is quite sparse/low-level requiring the user of the API to drop down to the underlying representation of Emit in order to deal with complexity (if you take a look at Virgil Kyo to see me struggling 😂). The underlying representation feels akin to ZIO’s channel or FS2’s Pull but it would be much nicer to offer more higher level combinators that prevent/delay the user of the API to reach for lower levels immediately and allows one to stay at a very high level of abstraction until one cannot and requires fine grained control and performance. The idea at least naively would be to eventually replicate the API surface (or provide similar or better expressivity) of the other 2 streaming libraries.
The text was updated successfully, but these errors were encountered: