It could be that the current names make sense if you work on v8, but don't if you work on a browser. Perhaps this naming scheme could be chromium-specific?
- a On Thu, Jul 9, 2009 at 1:50 PM, Mads Sig Ager<[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
