W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 10 Apr 2006 19:36:41 -0700
Message-ID: <443B1639.4070800@sicking.cc>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, Cameron McCormack <cam@mcc.id.au>, Web APIs WG <public-webapi@w3.org>

>>>>>>> [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
>>>>>> 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').
> I noted that the XMLHttpRequest property should be defined in the 
> ECMAScript bindings to also have the [[Construct]] internal property. So 
> you could write either what you said, or
> myXHR = new XMLHttpRequest();
> Which I think does add a new way to do it, but corresponds well to the 
> way constructor functions work for ECMAScript built-in classes (they can 
> all also be called as functions).

But if the new signature is not compatible with existing script, then 
why both making them 'almost equal'? I'd say that it'd be better to put 
a 'createXMLHttpRequest' function on DOMImplementation then.

/ Jonas
Received on Tuesday, 11 April 2006 02:37:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC