On 4/21/14, 11:35 PM, Joshua Cranmer 🐧 wrote:
I'm referring to using a Promise, essentially, in backend code of
Thunderbird. There is no "window"
I mean Window in the "DOM Window" sense.
Promises can be created using some other global (which one is up to the
person creating it), but typically they're associated with a Window.
Of course if you're doing something that doesn't look like anything in
the web platform then using web platform APIs may give you a bad time,
though... :(
Maybe if I clarified that I meant that "object x is a promise if...".
Promises, AFAICT from observing at a great distance the ES6 discussions,
are not tied to specific JS or DOM objects but rather the existence of a
single method
You're confusing "Promises" and "thenables". They behave somewhat
differently in various ways (not least in terms of what Promise.resolve
does with them).
The main thing that's special in the spec wrt thenables is that they are
treated specially when they happen to be return values from a
resolution/rejection handler.
I'm not following this.
In order to react to a promise, you need to wrap a C++ function into a
JS callable function.
Can you back up a second?
What do you mean by "react to a promise"? Do you mean the equivalent of
invoking its then() method (so being notified when it's resolved or
rejected)?
If so, if your promise is an actual Promise then you implement a
subclass of PromiseNativeHandler and call Promise::AppendNativeHandler()
with an instance of that subclass. No JS callables involved, though of
course you will get resolved/rejected with a JS::Value and then have to
deal with it.
I consider manual JSAPI calls pretty hairy already
I think we can all agree that minimizing the amount of manual JSAPI that
needs to be done is a goal here.
I'm not following the reasoning, but chances are it's wrong. Unless
you need your thing to be gettable from C++ via
createInstace/getService, you shouldn't need XPIDL.
That is exactly what my need.
OK.
Note that this still does not require XPIDL; it just makes object
creation a bit more annoying if the object is using WebIDL bindings
instead [1]. Whether that annoyance is a bigger problem than the other
issues you get when using XPIDL here is hard for me to tell given the
lack of context.
I don't have any other choice.
Sure you do. You can use raw JSAPI (yes, you don't want to and I don't
want you to) or WebIDL. Again, it's a matter of tradeoffs...
Hopefully the fact that I need to go through XPIDL is sufficient
explanation.
See above. It would really help if you'd just explain what you're
trying to do instead of talking about the solutions to a problem that's
not actually stated...
-Boris
[1] You can have an object that has a WebIDL binding and implements a
contract that QIs only to nsISupports, then createInstance it, QI to
nsIXPConnectWrappedJS, extract the chrome-side JS::Value and then
construct the webidl binding object. In fact, this is exactly how
JS-implemented WebIDL bindings work.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
