638
edits
Roadmap for language agnostic scripting support: Difference between revisions
Roadmap for language agnostic scripting support (view source)
Revision as of 16:43, 14 September 2007
, 14 September 2007fix plus signs in migrated content
No edit summary |
m (fix plus signs in migrated content) |
||
| 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. | ||