-
-
Notifications
You must be signed in to change notification settings - Fork 157
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
RFC: Public Yieldables API #413
Conversation
Looks great! Glad you're making this more public. I like that some of the ugly internals for "resuming" within the yieldable are hidden. One thing though:
I would change this so that you can resume a yieldable instance across calls. A Yieldable should be more like a stateless "description" of the async operation you want to build when e-c processes the Yieldable you yield to it. This is the basic idea behind Rx Observables: the observable objects don't have any state on them until you From what I gather, I don't think making this change would actually change the public API for building yieldables, and it has the nice benefit that you would be able to reuse yieldable instances across calls, e.g.
vs having to wrap |
@machty I think I might have phrased this weirdly... it is safe to use across calls within the same TaskInstance execution, but not across different TaskInstances. i.e. yes, you can make one call to const myTimeout = timeout(500);
class MyClass {
@task *aTask() {
yield myTimeout
}
@task *bTask() {
yield myTimeout;
}
} ^ This would not be allowed. If we want to allow that, I think we can do that, although the API might need to be a little bit different, especially to accomidate Promise casting of yieldables (which I just realized I forgot to define.) |
This is actually how Yieldables worked internally before and makes it easier to avoid sharing taskInstance at the class-level, making suitable for cross-call, and cross-task use of a single instance of a Yieldable
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@machty Revised the RFC last night a little bit in order to introduce Otherwise I think I'll probably move forward with this approach. |
Rendered
Implementation is included as well, which shows refactor of built-in Yieldables to use the new API. Refactoring (or similar) will probably stand, regardless of whether to promote to public API, as calling
taskInstance.proceed
with various magic values in a bunch of places is error prone.