- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 09 Sep 2011 14:28:53 +1000
- 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