You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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)
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
byCaseImpl
(better name wouldn't hurt), which looks likeCaseObject
but has a differentexecute
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 returnedAssertsions
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.The text was updated successfully, but these errors were encountered: