This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If class string is an internal property of an object, then it should be defined as [[ClassString]] to be consistant with ECMAScript. It's confusing to bounce from conceptual definitions to object property definitions. Also, there is a pattern to expose all internal properties of an object in ECMAScript5. I think it should be the assumption that Class String will also eventually be exposed to script (or should be explicitly defined to be!). If anything, for sanity, give the class string contant names: platform object: "Platform" interface prototype object: = "Prototype" exception interface prototype = "Exception" or some such. This would be consistant with the use of ECMAScript5 Type(x). In the case of WebIDL, it should be referred to as ClassType(x), then in prose: If ClassType(x) is "Platform"...
Internal properties are really just conceptual definitions anyway, they're not expected to exist on the property internally necessarily. I don't believe there is a way to expose arbitrary internal properties from ES5 objects. I define the class string solely to avoid redefining [[Class]], to make it possible for pure JS implementations to have Object.prototype.toString behave appropriately. I think at some point ECMAScript is going to gain an internal property like this, but I don't think they have done so yet. When they do, we can rewrite Web IDL to use that rather having the "class string" definition. I don't think it makes sense to have all platform objects return "[object Platform]".
I think it is fine how it is, and we definitely don't want to use strings like "Platform".