Breaking the grip JS has on the DOM: Difference between revisions

Jump to navigation Jump to search

Breaking the grip JS has on the DOM (view source)

Revision as of 05:48, 3 September 2005

602 bytes added ,  3 September 2005
More updates for the current state of the world.
(note that we are keeping the "void *aScopeObject" and not replacing with the nsIScriptGlobalObject)
(More updates for the current state of the world.)
Line 5: Line 5:


Ideally, the first step could be done without consideration for the second, in the assumption at the implementation should be truly language neutral.  However, this first real implementation is likely to impact the design decisions made, so there will be some iteration involved
Ideally, the first step could be done without consideration for the second, in the assumption at the implementation should be truly language neutral.  However, this first real implementation is likely to impact the design decisions made, so there will be some iteration involved
This work is initially being done on a DOM_AGNOSTIC_BRANCH cvs branch.


== Original specification - stage 1 ==
== Original specification - stage 1 ==
Line 28: Line 30:
=== Overview ===
=== Overview ===


A new interface nsILanguageRuntime will be implemented for each language.  It is a singleton (JS will be manually instantiated, but all other languages will be services).  nsDOMScriptObjectFactory will become the factory for these nsILanguageRuntimes, with the language runtime taking responsibility for creating nsIScriptContexts.
   
The existing nsIScriptContext interface will remain tied to a specific language.  The "void *" params in its interface will remain.  This means that a "void *" and a suitable nsIScriptContext must always be treated as a pair (ie, given just a "void *", there is no way to determine an appropriate nsIScriptContext suitable for it - although "assume JS" is likely to remain for existing code that does exactly this)
The existing nsIScriptContext interface will remain tied to a specific language.  The "void *" params in its interface will remain.  This means that a "void *" and a suitable nsIScriptContext must always be treated as a pair (ie, given just a "void *", there is no way to determine an appropriate nsIScriptContext suitable for it - although "assume JS" is likely to remain for existing code that does exactly this)
nsIProgrammingLanguage constants will internally identify a language lending to an efficient array-based implementation whenever an object per language is required.  The nsIDOMScriptObjectFactory will be able to convert language named to IDs and will be responsible for instantiating new language runtimes.


nsIScriptContext will grow new methods relating to:
nsIScriptContext will grow new methods relating to:
* language specific cleanup and "default language context" type code.  For example, nsGlobalWindow.cpp has a number of calls to ::JS_ClearScope/::JS_ClearWatchPointsForObject etc - these need to be hidden behind one of the interfaces.
* language specific cleanup and "default language context" type code.  For example, nsGlobalWindow.cpp has a number of calls to ::JS_ClearScope/::JS_ClearWatchPointsForObject etc - these need to be hidden behind one of the interfaces.
* The "WrapNative" process (or possibly this can be hidden behind JS 'SetProperty' functions?)
* The "WrapNative" process, which is used to locate a language native object "bound" to a DOM object pointer.


The existing nsIScriptGlobalObject interface will move towards a model where there is a global nsIScriptContext per language.  GetGlobalJSObject and GetContext would be deprecated, with a new method allowing the desired language to be specified.  Thus, nsIScriptGlobalObject may have many nsIScriptContexts associated with it (one per supported and initialized language)
The existing nsIScriptGlobalObject interface will move towards a model where there is a global nsIScriptContext per language.  GetGlobalJSObject and GetContext would be replaced with GetLanguage* methods (hard-coding nsIProgrammingLanguage::JAVASCRIPT) where necessary.  Thus, nsIScriptGlobalObject may have many nsIScriptContexts associated with it (one per supported and initialized language)


A new 'context stack' will be invented:
A new 'context stack' will be invented:
Line 40: Line 46:
* Contexts for *all* languages are pushed and poped as a single operation - a new context applies to all languages in the environment, not just a single one.  This is so when calls cross multiple language boundaries, they always have a correct context, not just the last one that happened to be pushed for their language.
* Contexts for *all* languages are pushed and poped as a single operation - a new context applies to all languages in the environment, not just a single one.  This is so when calls cross multiple language boundaries, they always have a correct context, not just the last one that happened to be pushed for their language.


nsDOMClassInfo will need a fair bit of work, and significant help from Mozilla resources.  It may be able to be split into a language neutral nsDOMClassInfo, and a JS specific nsIXPCScriptable.  The JS specific code in this file will need to be re-written for Python, but this should allow all DOM knowledge to be reused by the Python implementation.
The special casing for js in nsDOMClassInfo will need a fair bit of work, and significant help from Mozilla resources.
 
nsIProgrammingLanguage constants will identify a language.  Existing occurances of a char * identifying a language or version may also be changed to also use an integer, allowing bitmasks etc.


Below are specific implementation notes:
Below are specific implementation notes:


=== new interface nsIScriptLanguage ===
=== new interface nsILanguageRuntime ===


* This is really only a factory for nsIScriptContext objects.  The nsIScriptContext itself becomes the factory for the language specific, void * "global object".
This is a factory for nsIScriptContext objects and has methods for parsing "version strings" into a version integer specific to the language.


nsJSEnvironment implements this interface and becomes the JS factory (and renamed to nsJSRuntime).  Public function for creating JSContext replaced with public function for the nsJSRuntime.
   
=== nsIScriptContext ===
=== nsIScriptContext ===


* Existing JSObject replaced with void
* Existing JSObject replaced with void
* Existing "char *version" replaced with "PRUint32 version".  nsILanguageRuntime able to convert a char * version string into the flags.


* Existing "void *aScopeObject" (ExecuteScript/EvaluateStringWithValue/CompileScript), is *not* replaced with nsIScriptGlobalObject.  This is a change from earlier versions of this document - nsXBLProtoImplField and a few others pass an explicit aScriptObject which is not the same as associated with the nsIScriptGlobal.
* Existing "void *aScopeObject" (ExecuteScript/EvaluateStringWithValue/CompileScript), is *not* replaced with nsIScriptGlobalObject.  This is a change from earlier versions of this document - nsXBLProtoImplField and a few others pass an explicit aScriptObject which is not the same as associated with the nsIScriptGlobal.
Line 58: Line 66:
* FinalizeClasses method - JS does the ClearScope/ClearWatchpointsForObject/ClearRegExpStatistics?
* FinalizeClasses method - JS does the ClearScope/ClearWatchpointsForObject/ClearRegExpStatistics?


* nsIArray to be used in place of JSVal argc/argv used now.
* nsIArray to be used in place of JSVal argc/argv used now.  nsIPropertyBag may be a better choice in some cases - eg, event args are less "argv" in concept and more "list of public names to put in the namespace".


* Maybe some kind of "SetProperty" function - as needed by nsGlobalWindow - "arguments", "navigator" etc.  http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#871 [Not sure this is needed. IMO we should make "arguments" be XPCOM objects, i.e. [nsIArray -- markh] and we'd finally be able to get to the arguments passed to window.open() from *any* language. "navigator" is just a property of a window like all others, except that there's some JS:isms around it that I think we can easily ignore for Python -- jst]
* Maybe some kind of "SetProperty" function - as needed by nsGlobalWindow - "arguments", "navigator" etc.  http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#871 [Not sure this is needed. IMO we should make "arguments" be XPCOM objects, i.e. [nsIArray -- markh] and we'd finally be able to get to the arguments passed to window.open() from *any* language. "navigator" is just a property of a window like all others, except that there's some JS:isms around it that I think we can easily ignore for Python -- jst]
Line 91: Line 99:


* Serializing scripts and fast-load needs thought.  Python could benefit from caching its compiled "code objects" to avoid parser overhead on each reload.  These "code objects" are just another "PyObject *", so abstracting and delegating fast-load to nsIScriptContext may be possible.
* Serializing scripts and fast-load needs thought.  Python could benefit from caching its compiled "code objects" to avoid parser overhead on each reload.  These "code objects" are just another "PyObject *", so abstracting and delegating fast-load to nsIScriptContext may be possible.
* CompileScript - We should consider fixing this:
  nsXulElement.  Line 3666:
  // XXXbe violate nsIScriptContext layering because its version parameter
  // is mis-typed as const char *
 


=== nsDOMClassInfo ===
=== nsDOMClassInfo ===
MarkH
32

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/11578"

Navigation menu