W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: [WebIDL] feedback document posted

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 09 Sep 2011 14:28:53 +1000
Message-ID: <4E699605.8060800@mcc.id.au>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
CC: public-script-coord@w3.org, Anne van Kesteren <annevk@opera.com>
On 8/09/11 6:33 PM, Cameron McCormack wrote:
>> Clause 3.2 Modules
>>
>> I appreciate the desire to eliminate modules, if they are currently
>> [not] being used by any specifications. However, this also seems short
>> sighted. In ECMA TC39 we generally try to be very conservative in
>> adding new names to the global name space (ie, properties of the
>> global object) because of the high probability that such names will
>> clash with user defined global names used by existing web pages. To the
>> extend that WebIDL names are converted to global ECMAScript names
>> (for example,interface names manifesting as ECMAScript constructor
>> functions), WebIDL and W3C specification have the same problem. Some
>> sort of name space qualification of global names introduced by W3C
>> specifications seems essential. If it isn’t accomplished via WebIDL
>> modules it needs to be specified in some other manner.
>
> I haven't seen any support expressed so far for using Web IDL modules
> with [NamespaceObject] so that interface object properties can be put on
> an object other than the global object.
>
> I guess what I wonder is: if ECMAScript modules become the accepted way
> to put JS library APIs in a namespace and to import them for use, will
> that also be the way that future Web platform APIs are namespaced too?
> This is something that I don't think has been discussed yet. I think it
> is premature for Web IDL to include a namespacing mechanism if we're not
> sure yet what we want to achieve for Web platform APIs in terms of
> namespacing.

I am going to leave the current text in the spec about modules, and 
reconsider removing them after the next document publication.
Received on Friday, 9 September 2011 04:29:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC