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

Re: [WebIDL] remove modules

From: timeless <timeless@gmail.com>
Date: Tue, 23 Aug 2011 10:14:17 -0400
Message-ID: <CAACrNNfYRyNQtu6PWV4tf2eUsns8_fmHqpwthMOP9cK_QpTP3Q@mail.gmail.com>
To: Robin Berjon <robin@berjon.com>, Bryan Sullivan <blsaws@gmail.com>, public-script-coord@w3.org

interface WACToaster {...};
partial interface WACWindow { attribute WACToaster toaster; };

That still pollutes window with WACToaster (interface object), but
since you shouldn't use instanceof anyway, no one is significantly

On 8/23/11, Robin Berjon <robin@berjon.com> wrote:
> Hi Bryan,
> On Aug 11, 2011, at 15:59 , Bryan Sullivan wrote:
>> If modules are removed from WebIDL, how will different specifications
>> ensure
>> that there are no namespace issues (i.e. conflicts between the names of
>> interfaces)? Sorry if I am misunderstanding the intent of the module
>> feature, but that is one aspect of how it was used in BONDI (which still
>> does exist it the market, BTW, in products but not as an actively
>> developed
>> specification) and WAC.
>> I am very interested in the stability of this spec, for WAC and also
>> because
>> I am leading work to begin using Web IDL in the Open Mobile Alliance, in
>> which we are creating Javascript APIs for exposure of OMA enabler
>> services.
>> We will have a variety of APIs being defined, and need to ensure that the
>> different specifications do not conflict in the naming of interfaces.
>> Without the module feature, how do we replace the capability for this
>> purpose?
> I don't think that modules help BONDI, WAC, and OMA as much as people there
> think that they do. I also think that there's a workaround.
> The requirement that I believe you have is that you should be able to add
> new interfaces to Web runtime engines without them clashing now or ever. So
> for instance if WAC creates an interface for toasters without anyone
> complaining, but ten years down the line W3C, browser vendors, etc. realise
> that they badly need toasters too no clash happens.
> You don't need modules for that, you just need some kind of namespacing. You
> could go really low-tech on this and all anything globally available you
> have WACSomething (e.g. WACToaster) but that gets tired fast and ugly
> faster. I think that your best design approach is to create one single
> global (unlikely to clash) for the entire organisation and place all your
> additions there. Effectively, it's a module but you can implement it using
> just interfaces. So you have a supplemental WACWindow that adds .wac to
> window, and then a supplemental Toaster that adds .toaster to .wac.
> Does that make sense?
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

Sent from my mobile device
Received on Tuesday, 23 August 2011 14:14:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC