Re: An import statement for Web IDL

Maciej Stachowiak:
> > > On possibility: we could consistently use modules and have a way
> > > to import by module name, a la Java. Specs could import other
> > > modules wholesale with prose or an IDL fragment at the top of the
> > > document. We could recommend that non-W3C spec specs should use
> > > "reverse DNS" style module prefixes to avoid the possibility of
> > > collision.
> > >
> > > This makes the name binding more rigorous than filename-based
> > > includes and should not overly get in the way of implementations
> > > or specs.

Ian Hickson:
> > I would rather have just one module for all of the Web platform,
> > since at the end of the day there's only one namespace in JS.

Maciej Stachowiak:
> If I were designing things from scratch, I would want to take this  
> approach. However, the DOM specs already have their own module names and 
> I don't think it's worth changing them. Reserving one particular module 
> for all new W3C specifications seems reasonable, but I'm not sure it's 
> better than one per spec.
>
> The point of using modules for this at all is to avoid non-W3C  
> specifications accidentally or intentionally clashing with the names,  
> though on further consideration, it seems like this would cause problems

It would cause problems with the flat namespace the JS usually uses,
though I’ll point out that the BONDI folks are reflecting their module
hierarchy into JS (bondi.something.InterfaceName).

Although in the usual case module structure isn’t reflected in JS, and
so interface objects all go on the global object, the module structure
IS used to determine the Java package name.  Without a module
declaration, there’s currently nowhere to get the package name from.
There is already a lot of code published that uses org.w3c.dom.Node and
org.w3c.dom.events.EventTarget, for example.  Were it not for that (or
if we can come up with an easy mechanism to specify the Java package
name even if there is no module structure for Web platform interfaces)
then I would also suggest to just ditch modules for our specs.

In HTML 5, Ian is considering the separate IDL fragments (with one or
two interfaces each) within the spec to be the actual IDL fragments that
are required to be implemented.  This is different from other (older)
specs, like the DOM specs, where the inline fragments in the main spec
are just excerpts from the actual IDL, which is included as a whole in
an appendix.  While the IDL in these specs’ appendices have ‘module { }’
around the interfaces, the excerpts in the main part of the spec do not.

It seems like Ian’s not willing to place ‘module html { }’ around each
IDL fragment in the HTML 5 spec.  Without that, these interfaces indeed
aren’t in the html module.  Some tricky defaults then place those, for
the Java binding, in the org.w3c.dom package.  I don’t know how
important it is to keep the HTML interfaces in the org.w3c.dom.html
package, but it definitely seems important to keep DOM Core and Events
interfaces in org.w3c.dom and org.w3c.dom.events.

I guess I can be happy with not having import statements at all, and
relying on some mechanism external to the IDL to state what the combined
bunch of IDL fragments required is.  The module issue is probably more
important, and it would require agreement from all of us who are writing
specs with IDL as to how we’re going to use modules.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 2 July 2009 06:43:20 UTC