On 4/22/14, 2:51 AM, Joshua Cranmer 🐧 wrote:
I'm giving to thinking in terms of all of the magic hiding that
XPIDL/XPCOM/xpconnect does, so things like "what is my global object"
being intrinsically important are annoying to me.

I understand that.

but something like Promises or TextEncoder
which is more or less like "syntactic sugar for code I could write but
don't want to"

The problem is that the global they're attached to is observable. For example, TextEncoder returns returns a typed array, and the returned object is obviously tied to some global...

When I create an nsIJSImplementedInterfaceMagicObject from C++, I don't
have to worry about global objects. Perhaps xpconnect should just expose
the "here's a dummy global if you need one" more easily?

xpc::GetJunkScopeGlobal exists (though perhaps not outside libxul?). You also need explicit approval from the xpconnect module owner to use it, because if you create objects in there and hand them to someone else they can tell you used the junk scope.

There's a tension here between hiding the implementation details and making sure people get them right if the code you hand your objects to decides to poke at them. :(

I've heard that Promises.jsm are still better to use than DOM Promises...

Clearly they're not if you need to deal with C++ code!

ToJSValue I think makes some of the pain of converting from T (for
almost any xpidl-usable type, at least) much less painful. A
corresponding FromJSValue could probably work well too.

We could certainly add some helpers for common operations like that, yes.

When I have some more time, I can try playing with some magic
prototype implementations and suggest which methods would be sufficient
to be useful for my needs.

That would be awesome!

The IDL annotation I think I'd want first is not defining these in the
mozilla::dom namespace.

We could do that, with enough work... but I suspect it would take a surprising amount of work. I'd like to see good reason for this one.

-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to