Re: random notes on the XHR editorial notes

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

Received on Wednesday, 5 April 2006 22:27:01 UTC