[webkit-dev] Question about Constructors in WebKit JS Bindings

[Drew Wilson]

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...

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090622/52175f22/attachment.html>