- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Wed, 5 Apr 2006 23:39:24 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Public Web API <public-webapi@w3.org>
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/
Received on Wednesday, 5 April 2006 21:39:24 UTC