Re: [WebIDL] Java package mapping
On Mon, 1 Dec 2008 11:12:13 +1100, Cameron McCormack [EMAIL PROTECTED] wrote: Done: http://dev.w3.org/2006/webapi/WebIDL/#idl-modules http://dev.w3.org/2006/webapi/WebIDL/#Prefix http://dev.w3.org/2006/webapi/WebIDL/#java-modules The example in the java-modules section has a typo; it says org.foo.ext.FooDocument instead of org.foo.ext.ExtendedFooDocument. Also, I'm not sure if this matters, but while implementing I realized that having both [TheExtendedAttribute=identifier] and [TheExtendedAttribute=ScopedName] leads to an ambiguous grammar, since [foo=bar] can be interpreted as both. Presumably this would lead to shift-reduce conflicts with a context-free parser generator. For my implementation I always resolve it to be a ScopedName and then use either the prefixed name or the unprefixed name depending on which attribute it is. Cheers, kats
Re: [WebIDL] Java package mapping
Kartikaya Gupta: The example in the java-modules section has a typo; it says org.foo.ext.FooDocument instead of org.foo.ext.ExtendedFooDocument. Thanks, fixed. Also, I'm not sure if this matters, but while implementing I realized that having both [TheExtendedAttribute=identifier] and [TheExtendedAttribute=ScopedName] leads to an ambiguous grammar, since [foo=bar] can be interpreted as both. Presumably this would lead to shift-reduce conflicts with a context-free parser generator. For my implementation I always resolve it to be a ScopedName and then use either the prefixed name or the unprefixed name depending on which attribute it is. Indeed, that’s part of why I’ve held off updating the grammar. I plan to change the grammar to parse any balanced content between commas in square brackets as an ExtendedAttribute, and to then have rules like: ExtendedAttributeScopedName → identifier = ScopedName along with a statement “if it matches ExtendedAttributeScopedName, then the extended argument takes a ScopedName”. This would happen to make some extended attributes be more than one of these types (like the single identifier matching both the ScopedName and identifier argument forms), but I wouldn’t have any extended attributes defined that could take both. The above would then allow me to say that any other balanced sequence of tokens that was found between commas is some extension that can be ignored. (Where by “balanced” I mean balanced brackets, quotes, etc., which should cover most cases that people would want to do in their own extended attributes.) -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] Java package mapping
Cameron McCormack:
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)?
Kartikaya Gupta:
Works for me.
Done:
http://dev.w3.org/2006/webapi/WebIDL/#idl-modules
http://dev.w3.org/2006/webapi/WebIDL/#Prefix
http://dev.w3.org/2006/webapi/WebIDL/#java-modules
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] Java package mapping
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 {
[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?
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
http://lachy.id.au/
http://www.opera.com/
Re: [WebIDL] Java package mapping (was: Re: [Selectors-API] IDL namespace)
On Fri, 28 Nov 2008 21:42:08 +1100, Cameron McCormack [EMAIL PROTECTED] 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
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/
