Robin Berjon wrote:
On Apr 05, 2006, at 23:24, Jonas Sicking wrote:
Robin Berjon wrote:
• "Need to define which IDL specification we are going to conform
to, if any."
This came up on xml-dev, where OMG IDL was blamed for the fact that
we have createElement() and createElementNS() in the DOM instead of
just one (there may be other reasons). I am all for forgetting
about OMG IDL, but I think we need to consider the following:
Some languages, like ECMAScript, don't have support for overloading,
so blaiming OMG IDL is a bit wrong.
ECMAScript isn't the language implementing these interfaces (just using
them), and even if it were it supports variable argument lists and
typeof which is all you need to implement.
ECMAScript is the implementation language for some interfaces, like
NodeFilter, XPathNSResolver and EventListener.
But yeah, you could probably stick the implementation of all overloaded
methods in a single function and then check the arguments array.
- some folks generate Java interfaces from the IDLs. I think we're
safe so long as we generate a binding from what we have (which is
easy to add to ReSpec, I can do it)
- some implementations (Mozilla?) seem to use OMG IDL. Would they
be fine with something else, or with hacking the something else
themselves, or if we generated something more kosher and let them
do whatever workaround they do to get around it for stuff they
already support?
Overloaded functions are a pain in mozilla. Since ECMAScript doesn't
have overloaded functions we end up having custom glue code
everywhere overloading and optional arguments exist. And since we're
using OMG IDL we have to stick functions with the same name in
separate interfaces which of course isn't a useful solution in the
long run.
But you have to deal with it already no? Notably for XHR. And is it as
painful for varying types and for optional arguments? Is there no way
of using DOMObject and then casting depending on the JS type? (just
asking)
Yes, we do deal with this already and every time we do the result is
worse then if there had been no overloading.
What we end up having to do is to have one interface that contains one
version of the function that takes the smallest subset of arguments that
is the same in all overloads, and another create a separate interface
that contains a version of the function that contains all arguments. The
latter is then marked as "hidden to scripts". The implementation of the
former then has to query the script-engine to see if any of the optional
arguments were provided and do datatype conversion manually on it.
Script callers will then end up using the first version and C++ callers
use the latter version.
This might get even worse now that we are adding support for multiple
script languages, but I have not yet seen the code for that.
Varying types could be even worse since you in theory would have to use
a separate interface for each overload, unless you can find a "lowest
common denominator". This is fine if the all types are objects, but if
an argument can be either a number or a string you have to create
number-Objects and string-Objects which is a hassle and bloats both
memory and sourcecode.
This is all a product of the fact that we have build our DOM scripting
implementation on a generic COM-scripting layer.
It is possible that this would be helped if we moved XPCOM away from
using OMG IDL, but that is a big change that I'm not sure if we could.
/ Jonas
