On Jun 22, 2009, at 10:07 PM, Adam Barth wrote:
On Mon, Jun 22, 2009 at 9:58 PM, Peter Kasting<pkast...@google.com>
wrote:
On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth <aba...@webkit.org>
wrote:
On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiak<m...@apple.com>
wrote:
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.
Yes. Almost everywhere you see this pattern it's incorrect. We
have
this bug a lot.
To be clear, are you saying the original pattern, or the "simpler"
one Drew
proposes is typically the incorrect one? (I assume the latter.)
The latter one. The V8 binding are better about this because we have
v8::Context::GetCurrent(), which often gives you the context the JSC
bindings have to manually manage.
I suspect most JS bindings in WebKit use the original more complicated
pattern Drew cited, instead of the more succinct but incorrect one.
Here's how the two bindings relate (if you look at both bindings and
wonder):
v8::Context::GetEntered() ~~ exec->dynamicGlobalObject()
v8::Context::GetCalling() ~~ exec->lexicalGlobalObject()
v8::Context::GetCurrent() ~~ ????
It might be good to add a similar "GetCurrent" concept to JSC
(although, hopefully with a better name) so we can remove all this
manual, error-prone caching / mark()ing.
What does the "current" context correspond to? How is it retrieved?
Guessing wildly based on the names, I'm assuming host functions in v8
have the equivalent of their own scope chain and thus in some sense
their own lexical global object. We could do that for JSC, except that
for most things it would be useless - it's only potentially useful for
DOM-level explicit constructors, since JS-level ones are supposed to
use the calling function's lexical global object as the basis for
everything, and most other host functions don't need it at all.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
