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

Maciej Stachowiak wrote:
> 
> 
> 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();
> }

No, that would mean that people in javascript should write:

myXHR = XMLHttpRequest();

(note the lack of 'new').

For it to work you'd have to do something like:

interface WindowXMLHttpRequest {
   readonly attribute XMLHttpRequestCreatorFunction;
}

where XMLHttpRequestCreatorFunction is a function that when called 
returns an XHR. Unfortunately I don't think that really maps well to Java.

/ Jonas

Received on Monday, 10 April 2006 18:50:49 UTC