To me dynamic and lexical makes no sense, so I don't think we should go there. Since you 'enter' a context through the API and you alway have a current context when executing code, I find the current terminology consistent with what is going on and consistent with the naming in the rest of the API. If we are to change the names, we need to make sure to keep the names consistent and meaningful.
-- Mads On Thu, Jul 9, 2009 at 1:43 PM, Adam Barth<[email protected]> wrote: > I support this. It look me a while to get my mind wrapped around > this, especially when reading JSC / V8 bindings code side-by-side. > Aligning with the JSC names would be even better. > > Adam > > > On Thu, Jul 9, 2009 at 1:39 PM, Aaron Boodman<[email protected]> wrote: >> >> I have a proposal for a rename of these functions. GetCurrent() and >> GetEntered() make sense when you understand the underlying V8 >> mechanism, but I think that the concept of a stack of contexts is more >> readily understandable to some random engineer walking in off the >> street. >> >> What if we renamed these things to eg: >> >> GetTopContext(); // Returns the top v8 context from the stack, eg the >> context of the currently executing code >> GetBottomContext() // Returns the bottom v8 context from the stack, >> eg the context where execution entered v8 >> >> - a >> >> On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Ager<[email protected]> wrote: >>> >>> Drew, >>> >>> quick answer: When you use V8 you have to enter a context before >>> giving V8 some code to execute. GetEntered() returns the last context >>> that you entered using the API. When you call JavaScript functions, >>> the JavaScript engine enters the context in which that function was >>> defined. When calling functions across frames, this context will be >>> different from the context that you entered through the API. >>> GetCurrent will always give you the context of the currently executing >>> function (the context in which the currently executing function was >>> declared). GetCalling will get you the context of the function that >>> called the function you are currently executing. >>> >>> Cheers, -- Mads >>> >>> On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilson<[email protected]> wrote: >>>> Hi all, >>>> I've been poking around quite a bit recently in the WebKit JS >>>> bindings/constructor code, trying to make some sense of their widespread >>>> use >>>> of the lexicalGlobalObject() - basically, it seems like looking at the >>>> lexicalGlobalObject() is seldom what they actually want, because it means >>>> that if you call between frames you unexpectedly start pulling things from >>>> a >>>> different context. >>>> As a very simple example (bear with me, I'll get to the chrome-specific >>>> question in a second) - imagine that you have a page containing a child >>>> frame. In the parent page, you define this: >>>> function getImage() { >>>> return new Image(); >>>> } >>>> ...now down in your child frame, you have code that does this: >>>> var image1 = new Image(); >>>> var image2 = parent.window.getImage(); >>>> assert(image1.__proto__ == image2.__proto__); // Fails in WebKit >>>> currently, >>>> because the Image constructor lookup uses the lexicalGlobalObject. >>>> >>>> JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect >>>> that >>>> they generally want to be using dynamicGlobalObject instead of >>>> lexicalGlobalObject when trying to access something from global scope. Or >>>> am >>>> I missing some subtlety here? >>>> That brings me to my Chromium/V8 question - there are 3 context-grabbing >>>> functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it >>>> appropriate to use one over the others (what are the effective >>>> differences)? >>>> The descriptions are kind of terse, and I'm afraid I'm missing some of the >>>> subtleties between "the context of the calling JavaScript code" vs "The >>>> context on the top of the stack" vs "The last entered context" (for >>>> example, >>>> I would have naively thought that the calling JavaScript code's context >>>> would *inherently* be the last entered one, and hence would be on the top >>>> of >>>> the stack, but clearly that's not true :) >>>> -atw >>>> > >>>> >>> >>> > >>> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
