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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 10 Apr 2006 14:12:03 -0700
Message-Id: <3CB0EF74-1CEA-494B-8A70-79A1DE68C7FD@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, Cameron McCormack <cam@mcc.id.au>, Web APIs WG <public-webapi@w3.org>
To: Jonas Sicking <jonas@sicking.cc>


On Apr 10, 2006, at 11:50 AM, Jonas Sicking wrote:

> 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').

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).

Regards,
Maciej


>
> 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 21:49:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT