W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2015

[Bug 28093] Consider using namespaceURI in the IDL

From: <bugzilla@jessica.w3.org>
Date: Wed, 25 Feb 2015 16:20:41 +0000
To: www-dom@w3.org
Message-ID: <bug-28093-4009-QzVqhfx03Y@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28093

Philip J├Ągenstedt <philipj@opera.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Philip J├Ągenstedt <philipj@opera.com> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 25 February 2015 16:20:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:23 UTC