Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Representing JS objects in DOM bindings
46 views
Skip to first unread message
Boris Zbarsky
Jun 23, 2012, 2:29:50 AM6/23/12
to
I've been looking into how we represent JS objects (needed in various
cases like callbacks) in DOM bindings. Right now we extract a JSObject*
from the JS::Value and then pass it into the C++ method. This is
clearly suboptimal in the moving GC world.
I believe I have several options at this point:
1) Just pass in the JS::Value& (after verifying that it's isObject()).
Pros: it's already rooted, nothing else to do. Cons: On the callee
side it's not obvious that this is guaranteed to be an ObjectValue. Or
maybe it's an ObjectOrNullValue? The callee has to rely on some sort of
out-of-band information to tell.
2) Put a RootedObject on the stack and pass a HandleObject to my
callee. This incurs a bit more of a performance penalty, and it's still
not clear how I make a distinction between "object" and "object or null".
Any others?
Does it make any sense to make things like ObjectValue subclasses of
Value instead of just functions, so I could use ObjectValue& or
ObjectOrNullValue& or whatnot as an argument? Or should I just stick
with RootedObject? If I do that, what are my options for being able to
distinguish between nullable and non-nullable objects?
-Boris
cases like callbacks) in DOM bindings. Right now we extract a JSObject*
from the JS::Value and then pass it into the C++ method. This is
clearly suboptimal in the moving GC world.
I believe I have several options at this point:
1) Just pass in the JS::Value& (after verifying that it's isObject()).
Pros: it's already rooted, nothing else to do. Cons: On the callee
side it's not obvious that this is guaranteed to be an ObjectValue. Or
maybe it's an ObjectOrNullValue? The callee has to rely on some sort of
out-of-band information to tell.
2) Put a RootedObject on the stack and pass a HandleObject to my
callee. This incurs a bit more of a performance penalty, and it's still
not clear how I make a distinction between "object" and "object or null".
Any others?
Does it make any sense to make things like ObjectValue subclasses of
Value instead of just functions, so I could use ObjectValue& or
ObjectOrNullValue& or whatnot as an argument? Or should I just stick
with RootedObject? If I do that, what are my options for being able to
distinguish between nullable and non-nullable objects?
-Boris
Jeff Walden
Jun 28, 2012, 7:04:00 PM6/28/12
to
On 06/22/2012 11:29 PM, Boris Zbarsky wrote:
> Does it make any sense to make things like ObjectValue subclasses of Value instead of just functions, so I could use ObjectValue& or ObjectOrNullValue& or whatnot as an argument?
This sounds good to me. Keeping everything as a Value as long as possible in general -- not just for this particular circumstance -- might even be a very minor performance win, in terms of not unboxing things until absolutely necessary.
> Does it make any sense to make things like ObjectValue subclasses of Value instead of just functions, so I could use ObjectValue& or ObjectOrNullValue& or whatnot as an argument?
Jeff
0 new messages