W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [WebIDL] Java package mapping (was: Re: [Selectors-API] IDL namespace)

From: Kartikaya Gupta <lists.webapps@stakface.com>
Date: Fri, 28 Nov 2008 14:06:39 +0000
To: Cameron McCormack <cam@mcc.id.au>
Cc: public-webapps@w3.org
Message-ID: <E1L63zw-00027C-MZ@bart.w3.org>

On Fri, 28 Nov 2008 21:42:08 +1100, Cameron McCormack <cam@mcc.id.au> wrote:
> 
> Alternatively: is it worth hard coding a Java package prefix into the
> spec, so that [JavaPackage] is not normally needed?  (This could map a
> module called ‘dom’ to org.w3c.dom, and other modules at the top
> level to org.w3c.dom.foo (for module events, module svg, etc.), unless
> overridden.)  And would this make Web IDL too specific for use by W3C
> specifications, and if it does, is that really a problem?
> 

I would prefer not hard-coding a package prefix. The implementation I just finished writing basically auto-generates a bunch of stuff from the DOM IDL files. Since it worked pretty well, we decided to create IDL files for some other proprietary interfaces so that we could auto-generate stuff for those interfaces too in a consistent manner. Those interfaces aren't in the org.w3c namespace, and hard-coding that prefix would make things more complicated. (My current implementation uses the [Prefix="..."] xattr from an earlier draft, which I'm fine with changing to Package or JavaPackage or whatever, as long as it allows specifying things outside of org.w3c as well).

On a somewhat related note, I realized that the [ImplementedOn] xattr takes an identifier rather than a fully-qualified name, which means that it can't properly be used for interfaces in another module. I thought that a typedef might be able to solve the problem but it doesn't in all cases:

module modA {
  interface intA {
  };
};
module modB {
  // typedef modA::intA intA;  // this would work, if not for the intA below
  interface intA {
  };
  [ImplementedOn=intA]  // this resolves to modB::intA. what if i want modA::intA?
  interface intB {
  };
};

I noticed you added a new [TheExtendedAttribute=packagename] production; I just thought it might be prudent to generalize that a bit more so that it can be used for [ImplementedOn] to specify a scoped name, or something to disambiguate the scenario above. The scenario itself is pretty unlikely, but if you're adding to the grammar anyway, then it shouldn't be too much effort to deal with this too.

Cheers,
kats
Received on Friday, 28 November 2008 14:07:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT