On Jun 22, 2009, at 5:54 PM, Drew Wilson wrote:
I notice that this is a fairly common idiom in the WebKit JS bindings:
1) Storing away a pointer to the JSDOMGlobalObject in the constructor
JSOptionConstructor::JSOptionConstructor(ExecState* exec,
JSDOMGlobalObject* globalObject)
: DOMObject(JSOptionConstructor::createStructure(exec-
>lexicalGlobalObject()->objectPrototype()))
, m_globalObject(globalObject)
{
2) Manually marking that JSDOMGlobalObject as in-use:
void JSOptionConstructor::mark()
{
DOMObject::mark();
if (!m_globalObject->marked())
m_globalObject->mark();
}
3) Using that stored-away JSDOMGlobalObject to get a reference to
the parent ScriptExecutionContext/Document:
Document* JSOptionConstructor::document() const
{
return static_cast<Document*>(m_globalObject-
>scriptExecutionContext());
}
static JSObject* constructHTMLOptionElement(ExecState* exec,
JSObject* constructor, const ArgList& args)
{
Document* document =
static_cast<JSOptionConstructor*>(constructor)->document();
I'm trying to understand why this is necessary - an alternative
would be to just do the following, as JSWorkerConstructor does:
static JSObject* constructHTMLOptionElement(ExecState* exec,
JSObject* constructor, const ArgList& args)
{
DOMWindow* window = asJSDOMWindow(exec->lexicalGlobalObject())-
>impl();
Document* document = window->document();
This avoids having to keep around a reference, have a custom mark()
function, etc. This also tightly ties a given constructor to a
specific Document object - in this particular example, my javascript
code could pass a reference to window.Option into a child iframe,
but executing the constructor within that iframe would still
reference the original Document object.
What's the motivation for storing away the original Document object
in these constructors? I'm writing a constructor for SharedWorker
now and I'm trying to figure out which is the correct behavior...
Your proposed alternative will have different behavior. It will use
the lexical global object of the calling JavaScript function, instead
of the global object originally associated with the Options
constructor. In the cross-frame case, this may give different results.
There is yet a third possibility, which is to save the original
document, rather than the original Window. This is what the
XMLHttpRequest spec requires for instance.
I would say the correct behavior here is whatever best matches the
spec and other browsers. I do not know that offhand, but I suspect
it's either the current behavior, or saving an original document
reference rather than an original window reference. I do not think
other browsers use the lexical global object of the calling function
in any cases like this.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
