638
edits
(New page: {{outdated|A lot of the work described here has already been done, e.g. mdc:XPCOM interface flattening.}} A long term goal for Mozilla is to support multiple scripting environments in...) |
m (fix plus signs in migrated content) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{outdated|A lot of the work described here has already been done, | {{outdated|A lot of the work described here has already been done. DOM is now exposed to JS entirely via XPIDL, and interface flattening is implemented.}} | ||
A long term goal for Mozilla is to support multiple scripting environments in addition to [[mdc:JavaScript|JavaScript]]; for example, [http://www.perl.org/ Perl] and [http://www.python.org/ Python]. This will allow developers to use the language of their choice to manipulate and implement components. Furthermore, a component will be able to manipulate (or be manipulated by) another component without regard for the language in which either is implemented. | A long term goal for Mozilla is to support multiple scripting environments in addition to [[mdc:JavaScript|JavaScript]]; for example, [http://www.perl.org/ Perl] and [http://www.python.org/ Python]. This will allow developers to use the language of their choice to manipulate and implement components. Furthermore, a component will be able to manipulate (or be manipulated by) another component without regard for the language in which either is implemented. | ||
Line 13: | Line 13: | ||
=== Replacing the DOM Binding with XPIDL Interfaces === | === Replacing the DOM Binding with XPIDL Interfaces === | ||
As noted above, we currently have two mechanisms for binding a script environment into Mozilla. The DOM binding uses generated C code to provide JavaScript-specific linkage, and was written to deal with the vagaries of the Level-0 JavaScript DOM. XPConnect uses a platform-independent ''type library'' with platform-specific method dispatch code to dynamically determine runtime binding. (footnote 1) | As noted above, we currently have two mechanisms for binding a script environment into Mozilla. The DOM binding uses generated C++ code to provide JavaScript-specific linkage, and was written to deal with the vagaries of the Level-0 JavaScript DOM. XPConnect uses a platform-independent ''type library'' with platform-specific method dispatch code to dynamically determine runtime binding. (footnote 1) | ||
The big first step towards supporting another scripting environment is to unify the current mechanisms used to integrate with JavaScript. This will involve a fair amount of work. | The big first step towards supporting another scripting environment is to unify the current mechanisms used to integrate with JavaScript. This will involve a fair amount of work. | ||
Line 32: | Line 32: | ||
== Notes == | == Notes == | ||
# There are many reasons that XPConnect is preferable over the generated C DOM binding: | # There are many reasons that XPConnect is preferable over the generated C++ DOM binding: | ||
#* XPIDL is far more expressive than the simple IDL used to define the DOM interfaces. (But currently not expressive enough to handle some of the DOM bindings: this is a problem that needs to be dealt with.) | #* XPIDL is far more expressive than the simple IDL used to define the DOM interfaces. (But currently not expressive enough to handle some of the DOM bindings: this is a problem that needs to be dealt with.) | ||
#* The type libraries that specify the runtime binding are a decimal order of magnitude more compact than generated C code. | #* The type libraries that specify the runtime binding are a decimal order of magnitude more compact than generated C++ code. | ||
#* XPConnect potentially allows for mediation between two (or more) different scripting environments. | #* XPConnect potentially allows for mediation between two (or more) different scripting environments. | ||
#* The generated C DOM binding is extremely JavaScript-specific, and it is extremely unlikely that any of it would be re-usable for another scripting language. | #* The generated C++ DOM binding is extremely JavaScript-specific, and it is extremely unlikely that any of it would be re-usable for another scripting language. | ||
# In fact, for a finite set of component types, we could hard code this in some simpler scheme. | # In fact, for a finite set of component types, we could hard code this in some simpler scheme. |
edits