Re: [WebIDL] remove modules

So:

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
harmed?

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