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

Remove tink_streams dependency. #23

Open
back2dos opened this issue Nov 18, 2021 · 1 comment
Open

Remove tink_streams dependency. #23

back2dos opened this issue Nov 18, 2021 · 1 comment

Comments

@back2dos
Copy link
Member

I forgot why exactly we decided to model everything with streams - other than the fact that it's super fancy. If there's a good reason to, then we should of course keep things as they are. Otherwise I'm inclined to remove them for the sake of simplicity.

A non-breaking approach would be to back Case by CaseImpl (better name wouldn't hurt), which looks like CaseObject but has a different execute method:

  • function execute(ctx:{ function report(a:Assertion):Void; function finish():Void; )->Void
  • function execute((report:Assertion)->Void)->Future<Noise>

I'm leaning towards the former one, because it's simpler still.

An implicit cast @:from CaseObject would then create an adapter that unrolls the returned Assertsions into the reporting function.

If we're fine with a breaking change, we can make the signature change on CaseObject directly. Since the main usage of this lib is via tink_unittest, it should be possible to leave all test suites based on it unaffected.

@kevinresol
Copy link
Member

kevinresol commented Nov 18, 2021

I think I originally started from a mind model that Case = Array<Assertion>, Suite = Array<Case>, etc (and Array could be async thus become Stream). That pure/functional approach was easier for me to reason about at a top-level view. But I think I do agree that makes the internal implementation more complex.

Anyway I think no one really use this lib directly so I guess a breaking change is fine. (if anyone actually does he will be a hardcore anyway and I guess wouldn't hurt much from a breaking change)

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

2 participants