These show up in Shark profiles and really shouldn't...
How about we just stick an mGlobalJSObject on nsIScriptGlobalObject, and make nsIScriptGlobalObject::GetGlobalJSObject inline and non-virtual? Then we wouldn't need this "fast" method, right?
(All that as a possible followup.)
Yeah, I'd rather do that as a followup, especially because nsIScriptGlobalObject is supposed to be language agnostic...
(In reply to comment #4) > > nsIScriptGlobalObject is supposed to be language agnostic... can we dispense with this agnosticism? it has ended up really costing us. At this point we have a lot platform that depends on JS anyway.
My only reservation about undoing that work is that we did sort of make a big deal of making it part of the platform at the time. This is a bigger question than can really be answered in this bug.
Mark, is the Python DOM stuff Working? Used? Owned? If none of the above, it is going to go. If two out of three we can talk. If one out of three, especially !Working but kinda-Used, then it's in trouble. /be
> especially because nsIScriptGlobalObject is supposed to be language agnostic I'm not suggesting we remove the language-agnostic global object getter. Just that we special-case the JS one, which we use extensively. I would also be just fine with inlining the language-agnostic one on nsIScriptGlobalObject, honestly.
AFAIK, sadly Python DOM is languishing - no regular users I am aware of, and AFAIK I remain the default owner although haven't touched it for years now.
My hope with PyDOM was to get people using true Python (C-Python) in lieu of JS. But the problem is no other browser offers such a thing. IronPython in the DLR on Silverlight scripting the IE DOM -- not the same! Mark, if you are ok with it (hg will remember), we will rip it out in an orderly fashion. We should have a newsgroup post about this. You game? /be
Separate bug needed. /be
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.