We should be able to do better than just methods that take JSValue. For example: [16:54:02] <bz> Right [16:54:05] <bz> now we have to call resolve [16:54:10] <bz> Which wants a jsval [16:54:25] <bz> And suddenly you have to create a jsval from your whatever-it-is [16:54:42] <bz> So in my proposal you would do this by writing this webidl: [16:55:01] <bz> callback MyFooWrapper = void (Foo arg); [16:55:16] <bz> which will cause WebIDL to codegen a C++ class called MyFooWrapper [16:55:23] <bz> which has a Call method taking a C++ Foo [16:55:47] <bz> Now the catch is that the MyFooWrapper ctor expects a callable JSObject* [16:55:57] <bz> So we would do: [16:56:25] <bz> nsRefPtr<MyFooWrapper> myWrapper = new MyFooWrapper(mPromise->GetResolveFunc()); [16:56:33] <bz> myWrapper->Call(myFoo); [16:57:05] <bz> Promise::GetResolveFunc would return a callable JSObject, which when called calls some C++ method over in Promise.cpp [16:57:15] <bz> which does the resolve
In particular, Promise already has the infrastructure for the GetResolveFunc() bit, since it does just that when its scripted constructor is invoked so that it can pass the resulting JSObject as an argument to the callback passed to the constructor.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 974120
You need to log in before you can comment on or make changes to this bug.