Re: ISSUE-73: Are we going to support non-ECMAScript languages?

On Apr 6, 2006, at 6:46 PM, Ian Hickson wrote:

>
> On Fri, 7 Apr 2006, Cameron McCormack wrote:
>>
>> Web APIs Issue Tracker:
>>>> [re creating an XHR object in non-ES languages]
>> ...
>>>> (a) Leave it up to the language
>>>> (b) Create a method on some object (like Window or Document)  
>>>> that returns an
>>>>     the object.
>>>> (c) Do it through DOMImplementation
>>
>> Ian Hickson:
>>> If you do either (b) or (c), please make it specific to that  
>>> language
>>> binding and no _not_ permit a JS implementation to expose that API.
>>
>> Why?
>
> Because every single code path adds a new set of bugs, with its own  
> set
> of Web pages that depend on it, with its own set of confused authors,
> with time spent implementing it, fixing it, testing it, etc.
>
> We already have at least three ways of obtaining an XMLHttpRequest  
> object,
> we don't need a fourth.

On the other hand, for implementations that provide bindings to  
multiple languages, it is a burden to exclude a particular API from  
only one of them. (WebKit is such an implementation, we have an  
Objective-C mapping to the DOM for use as part of the embedding API).

Here's a possibly too cute solution that would make things language- 
independent but add nothing new for JavaScript:

interface WindowXMLHttpRequest {
     XMLHttpRequest XMLHttpRequest();
}

In other words, require a function on the global object named  
XMLHttpRequest which makes a new instance for you.

And for JavaScript allow it to be used as a constructor too.

In fact this fairly accurately describes what current implementations  
already do.

Regards,
Maciej