Re: [webidl] definition of const string literal

Max Froumentin:
> > > The grammar in http://dev.w3.org/2006/webapi/WebIDL/ prevents
> > > declarations such as:
> > >
> > > const DOMString foo = "bar";
> > >
> > > because the "ConstExp" rule [1] only allows a number, or "TRUE" or
> > > "FALSE". Is it an omission?

It’s an omission in that string constants are omitted from the spec,
yes. :-)  It was a deliberate omission, which stems from DOMString not
being a primitive type at one point.  Also, I haven’t come across any
specs that need to have string constants yet.

Anne van Kesteren:
> > What is the use case? Web APIs usually work with numbers (if they have
> > constants at all).

Max Froumentin:
> I was wondering that too. But if there are no use cases, then the spec
> should be changed to disallow "const DOMString foo;". I'd disallow
> boolean too, in fact, but leave number constants.

It does disallow “const DOMString foo;” just by virtue of the fact that
there’s no way to represent a string literal, and the production for
consts requires an “= value” in there.

Booleans: yeah I could see they’re not that useful either.  I included
them because OMG IDL had them.  But I also haven’t seen them used in
existing specs.


Shiki, I notice that in your es-operating-system project you’re using
booleans and strings in consts, but just in the test suite.  Do you need
these types in practice?

(Also I see that you’re using the “string” and “wstring”, and L"wide
string" values.  Are you of the opinion that Web IDL should introduce
those instead of DOMString?)

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

Received on Tuesday, 28 April 2009 00:54:53 UTC