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

Re: [WebIDL] Java package mapping

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Fri, 28 Nov 2008 12:38:11 +0100
Message-ID: <492FD823.7030702@lachy.id.au>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapps@w3.org

Cameron McCormack wrote:
> Lachlan Hunt:
>> It seems from the Java bindings section of Web IDL that the way to  
>> define modules and how they're mapped to Java packages isn't yet very  
>> stable.
> I’ve added a way to specify the Java package naming method now:
>   http://dev.w3.org/2006/webapi/WebIDL/#JavaPackage
> So in selectors-api you would write:
>   [JavaPackage=org.w3c.dom]
>   module dom {
>     interface NodeSelector { … };
>   }

Could it just be called [Package] instead of [JavaPackage]?  The 
ECMAScript-specific extended attributes like [Callback] and [Undefined] 
don't contain the name of the language in their names, why should it do 
so for Java?

> I’d be open to having [JavaPackagePrefix=org.w3c] if the repetition of
> “dom” is sufficiently unsightly.

Why couldn't you just use [Package=org.w3c] and define that to be a prefix?

Also, you need to define what it means if [Package] is used on a nested 
module, or perhaps define that it's not allowed. e.g.

module dom {
   module html {

In which java package should the html module be, in that case? 
org.w3c.dom.html or org.w3c.html?

> 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'm not sure if that approach would be a good idea or not, although it 
would be convenient for W3C DOM specs.

Lachlan Hunt - Opera Software
Received on Friday, 28 November 2008 11:38:51 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC