Re: [WebIDL] change argument names from identifiers

Anne van Kesteren:
> It would be nice if argument names were not identifiers, so "callback"
> can be used as in:
>
> foo(optional Listener? callback)
>
> Argument names should mean nothing whatsoever and as far as I can tell
> you can disambiguate them already. Both DOM and HTML ran into this problem.

First, escaping exists exactly so that you can use any keyword as an 
identifier.  Although it doesn't seem to be that important for an 
argument name, so you could easily change what you use there. :)

But if we are going to relax the need to escape keywords to use them as 
identifiers for arguments, I think we should look to do it in all places 
where it's no ambiguous to do so.

Let's first assume that we disallow the keywords for the built-in types 
("long", "any", "object", etc.).

Then let's say we group usage of identifiers as follows, and have the 
escaping rules be consistent in each group:

   1. named definitions (interface, partial interface, dictionary,
      exception, enum, callback and typedef)
   2. members (operations, const, attribute, exception field, dictionary
      member)
   3. operation arguments
   4. extended attributes

Everything in the first group can be used as a type, so we should 
probably have the escaping rules for them be the same at the point of 
definition as they are when you reference them as a type.  So they can't 
be "const", because of

   interface const { };
   exception A {
     const x;
   };

(is the "const" introducing a const or an exception field?).

It also can't be "optional", because of

   interface optional { };
   void f(optional x);      -- is "optional" the interface type?


In the second group, we can't use "readonly", "attribute", "inherit", 
"const", "static", "getter", "setter", "creator", "deleter", 
"stringifier", or the keywords for built-in types.  All other keywords work:

   interface A {
     attribute Function callback;
   };


In the third and fourth groups, there aren't any restrictions on what 
keywords we could allow.


However, it complicates parsing, is not obvious when you need to escape 
and when you do not, and may look confusing to people reading the IDL. 
I'm not at all sure that we should do this.

I wonder if the "_" that performs identifier escaping should be "\". 
Then it doesn't look like it could be a normal identifier if you don't 
know what the escaping rules are.

Received on Monday, 5 March 2012 03:05:20 UTC