Skip to content
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

Consider Parse API refactor #326

Open
suyashkumar opened this issue Jun 1, 2024 · 1 comment
Open

Consider Parse API refactor #326

suyashkumar opened this issue Jun 1, 2024 · 1 comment

Comments

@suyashkumar
Copy link
Owner

suyashkumar commented Jun 1, 2024

Considering a Parse API refactor along with the next round of API-breaking changes. However, since the Parse API is likely the most used API we should be careful and only change it when we've gotten it right and are ready to commit.

Couple high level thoughts:

  • Let's only take io.Reader and read till EOF, and not require bytesToRead (and deprecate ParseUntilEOF)
  • Extra optional options (e.g. frame channel) can be passed via custom ParseOptions if required.
    • Do people find the frame channel useful and still want it?

Something like

func NewParser(in io.Reader, opts ...ParseOption) (*Parser, error) {} // To use with Parser.Next() API

func Parse(in io.Reader, opts ...ParseOption) (Dataset, error) {} // To get a Dataset directly

Open thoughts:

  • Do we still want to keep ParseFile around as a convenience (and update it to the new format)?
  • Do we like the ParseOption API / patterns / ergonomics, or would an options struct be better?
@suyashkumar
Copy link
Owner Author

@wkoszek @lnogueir and others feel free to weigh in!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant