This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'm trying to get Blink's IDL as close as possible to the spec, but because namespace is a C++ keyword it cannot be used, at least not without special-casing the code generator. Our IDL files use namespaceURI, which seems to be from the older DOM specs. Any other browser implemented in C++ will have the same "problem".
Could you please be more specific? I'm not sure I follow.
Isn't that just about how you map idl methods to C++. In Gecko Node's readonly attribute DOMString? namespaceURI; for example becomes void GetNamespaceURI(nsAString& aNamespaceURI) In case binary name must be something else, Gecko has https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#BinaryName
It might help if you said which "namespace" instance you're talking about. That said.... > at least not without special-casing the code generator. This is a problem all over, no? Specifically, I'm aware of at least the following cases in which C++ keywords of various sorts are used in IDL in various capacities: 1) Methods named "delete" on at least FontFaceSet, Headers, URLSearchParams, IDBCursor. 2) A method named "default" on FetchEvent. 3) A method named "continue" on IDBCursor. 4) A method named "register" on ServiceWorkerContainer. and there are probably more; these were just the ones that would have led Gecko's codegen to spit out the keyword in C++ code, which of course depends on the details of our codegen (and in particular we only end up using the original IDL name for method names; for example we typically don't use the argument names from the IDL for anything, so argument names don't show up in the list above much, we modify the case of dictionary members, so dictionary member names don't show up above, etc). What we end up doing in practice is that we have a blacklist of C++ keywords and we munge things that we'd spit out as barewords in C++ if they're in that blacklist. See <http://hg.mozilla.org/mozilla-central/file/b74938ef94bc/dom/bindings/Codegen.py#l7703>. I recommend doing something similar in your codegen, because restricting web specs based on what the set of keywords in C++ happens to be and what the internals of some particular code generators spitting out C++ look like is not really desirable.
(In reply to Boris Zbarsky from comment #3) > It might help if you said which "namespace" instance you're talking about. I'm talking about the DOMString? namespace arguments to many functions, the one I happened to try renaming yesterday was for NamedNodeMap.getNamedItemNS. > That said.... > > > at least not without special-casing the code generator. > > This is a problem all over, no? Specifically, I'm aware of at least the > following cases in which C++ keywords of various sorts are used in IDL in > various capacities: > > 1) Methods named "delete" on at least FontFaceSet, Headers, URLSearchParams, > IDBCursor. > 2) A method named "default" on FetchEvent. > 3) A method named "continue" on IDBCursor. > 4) A method named "register" on ServiceWorkerContainer. > > and there are probably more; these were just the ones that would have led > Gecko's codegen to spit out the keyword in C++ code, which of course depends > on the details of our codegen (and in particular we only end up using the > original IDL name for method names; for example we typically don't use the > argument names from the IDL for anything, so argument names don't show up in > the list above much, we modify the case of dictionary members, so dictionary > member names don't show up above, etc). > > What we end up doing in practice is that we have a blacklist of C++ keywords > and we munge things that we'd spit out as barewords in C++ if they're in > that blacklist. See > <http://hg.mozilla.org/mozilla-central/file/b74938ef94bc/dom/bindings/ > Codegen.py#l7703>. I recommend doing something similar in your codegen, > because restricting web specs based on what the set of keywords in C++ > happens to be and what the internals of some particular code generators > spitting out C++ look like is not really desirable. It looks like for methods that are keywords, Blink's IDL files use [ImplementedAs=remove] or similar to avoid the problem. Thanks for pointing out that the problem exists elsewhere. It looks like a better solution than changing the spec would be to deal with all of these with a mapping in the code generator. I see that Gecko has "DOMString? namespace" in its IDL files already, so I'll WONTFIX this.