Re: [WebIDL] Java package mapping

Lachlan Hunt:
> 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?

My reasoning for naming it [JavaPackage] rather than [Package] was that
different languages tend to have different conventions for package
naming, and that the reverse domain name style that you’d use as the
argument here wouldn’t be applicable to all languages.

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

Yes maybe it should go back to that style (like the proposed [Prefix]).
Again, though, the naming scheme used by W3C specs so far (lowercase
short module names at the top level) wouldn’t necessarily map nicely to
other languages (where maybe initial-case package names are used, for
example).

> 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 {
>   [Package=org.w3c]
>   module html {
>     ...
>   }
> }
>
> In which java package should the html module be, in that case?  
> org.w3c.dom.html or org.w3c.html?

With [JavaPackage] that is defined, at the moment.  It’d be
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.

Yes it would.


Kartikaya Gupta:
> 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).

OK.  The hard coded prefix approach I suggested above would still have a
mechanism for overriding that.  For example:

  module dom { interface Node { … }; };

  module svg { interface SVGElement : Element { … }; };

  [Prefix=org]
  module acme { interace NiftyElement : Element { … }; };

could result in interfaces org.w3c.dom.Node, org.w3c.dom.svg.SVGElement
and org.acme.NiftyElement.  [Prefix] could take a scoped name, and then
language bindings other than Java could define how that module name with
the prefix is mapped to the namespacing mechanism of that languages
(changing to camel case, or whatever) if needed.

Would that work for you (and Lachy)?

> 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 {
>   };
> };

Good point, I should change this to be a scoped name argument.

> 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.

Yes, though I thought that if [JavaPackage] was specifically for giving
the Java package name, that I’d use Java syntax for that (dots between
components, rather than “::”).

I haven’t made the grammar changes yet.  I’ll leave that until I get to
reworking it to have more robust parsing of extended attributes.

Thanks,

Cameron

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

Received on Saturday, 29 November 2008 02:16:57 UTC