[webkit-dev] Question about Constructors in WebKit JS Bindings
Maciej Stachowiak
mjs at apple.com
Mon Jun 22 19:04:30 PDT 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090622/b36922f5/attachment.html>
More information about the webkit-dev
mailing list