On 4/19/18 3:53 PM, Gijs Kruitbosch wrote:
If I understand correctly, with these changes I could now just use
Promise instead.
Not yet, as Andrew said. This just makes things declared as "interface
Something { ... }" in .webidl files work. Promise is not one of those
things.
That said, I expect that bug 1455217 will land Very Soon Now.
Also, we have existing magic in XPConnect to make it possible to pass a
Promise as nsISupports through XPConnect. Specifically, the rules are
as follows:
1) When doing a C++-to-JS conversion, if the type is nsISupports (or
Promise after Nika's patches in bug 1455217) and the C++ thing is a
dom::Promise, it gets converted to the underlying SpiderMonkey Promise
object.
2) When doing a JS-to-C++ conversion, if the type is nsISupports and
the JS thing being passed is a SpiderMonkey Promise, it gets wrapped up
in a dom::Promise and the nsISupports* pointer to that is passed to the
C++ code.
So today, before Nika's fix, you can write this idl:
nsISupports doAsyncFoo(); // Implemented in JS
and call it from C++ like so:
nsCOMPtr<nsISupports> result;
myThing->DoAsync(getter_AddRefs(result));
RefPtr<Promise> promise = do_QueryObject(result);
if (!promise) {
// Callee messed up and returned a non-promise
}
// Work with "promise".
Is that correct? Can I declare it including the
resolution result of the promise
Note that the resolution type is purely documentation in webidl; it
doesn't affect any behavior. A function could have Promise<long> as its
idl return type but mess up and and return a Promise resolved with a
Node and the bindings won't stop it.
The xpconnect fix above does not add that syntax; it just adds "Promise"
with no type parameter.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
