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.
- 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)
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
