Dumb question because I don't do this very often - sorry!
I am intending to async-ify a sync JS-implemented idl-defined API (which currently returns an unsigned long), that has a few C++ consumers. I was thinking the simplest solution would be a separate method definition in the idl that took a separate interface (nsIFooCallback) that then got the long and/or any other data we needed to pass. This because returning a promise seems to previously have involved returning jsval and then things get more complicated from there. The only in-tree .idl uses I saw for Promise are in the wpt test idl files, which I presume don't reflect our ability to implement that as a return type.
If I understand correctly, with these changes I could now just use Promise instead. Is that correct? Can I declare it including the resolution result of the promise, ie can I now use:
Promise<unsigned long> asyncGetFoo() in xpidl? Because that would make my life considerably easier... ~ Gijs On 19/04/2018 04:19, Nika Layzell wrote:
Yesterday, bug 1444991 <https://bugzilla.mozilla.org/show_bug.cgi?id=1444991> landed on inbound, which adds support for using WebIDL defined objects directly inside of XPIDL definition files. This allows us to avoid using nsISupports to pass WebIDL objects which don't have corresponding XPIDL interfaces through XPIDL defined methods. WebIDL objects must be forward declared, like XPIDL types, in the .idl file which uses them: // C++ 'nsFrameLoader', from FrameLoader.webidl webidl FrameLoader; // C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl webidl DataTransfer; These types may then be used like XPIDL types in method and attribute declarations. These types can be used from both C++ and JS code. They are exposed into Rust as '*const ::libc::c_void`. - NIka
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
