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
Pass resolver to then? #46
Comments
The main concern I would have is giving up future extensibility. I.e. if we pass the resolver as the second argument it means that we couldn't use that for something else. For example, I've always found it an intriguing idea to change the signature of So I should probably give up on that idea :-) But maybe it's worth calling I.e. the code would look something like: doAsync.then(function(v, { resolver: r }) {
r.accept(v+1);
}).then(...); But maybe that means that we're avoiding to create the Future but instead end up creating a dictionary. |
I don't think this is crazy, but it falls on the side of not-great idea rather than good one, mainly for portability reasons. In general, I think
function parseJSONPromise(promise) {
return promise.then(function (string) {
return JSON.parse(string);
});
} is reusable because it uses only the basic protocol, and can be reused no matter if you're using a raw DOMFuture, or if you're consuming Q/RSVP promises proxying remote objects via Q-Connection/Oasis, or if you're using WinJS promises created by the Windows Runtime, or... However, a function like this function parseJSONPromise(promise) {
return promise.then(function (string, resolutionCallbacks) {
resolutionCallbacks.resolve(JSON.parse(string));
return resolutionCallbacks;
});
} is not portable and will behave very differently when used with DOMFuture promises versus when used with promises from other systems. That is, it fulfills with If we instead specified a separate function, say function parseJSONDOMFuture(domFuture) {
return domFuture.thenWithResolutionCallbacks(function (string, resolutionCallbacks) {
resolutionCallbacks.resolve(JSON.parse(string));
return resolutionCallbacks;
});
} Finally, it's worth noting that the use cases for this method are pretty small. The only time it would avoid allocations would be when interfacing with non-promise async code inside the settlement handlers. (The above is actually an example of when you shouldn't use it---but, I'd be afraid people would.) In my experience working with promises, these interfaces almost never occur inside of the settlement handlers, but instead occur at the start of the promise chain. So I'd argue YAGNI, and that at the very least we should wait until people run into garbage-collection harm before considering extending the API with something that allows user optimizing. |
We can reconsider a feature like this in future if this actually turns out to be a problem. |
Merging of returned Futures is a good feature, but by default it creates a lot of objects for the GC to clean up. I worry that our current design creates the need for alloc when it isn't strictly necessary. One way around this is to provide the resolver to the then callbacks, allowing them to drive the lifecycle of the vended future directly (vs. merging). Merging is, of course, still supported, but savvy
then()
users could prevent mandatory alloc by returning the Resolver instead of a Future, signaling that they want to drive the process.Crazy?
The text was updated successfully, but these errors were encountered: