16450 2012-03-20 15:42:51 +0000 Class String 2012-03-27 00:06:28 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified DEC Neutrino RESOLVED WONTFIX P2 normal --- 1 w3c cam mike public-script-coord public-webapps-bugzilla oldest_to_newest 65845 0 w3c 2012-03-20 15:42:51 +0000 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"... 65929 1 cam 2012-03-21 22:51:03 +0000 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]". 66088 2 cam 2012-03-27 00:06:28 +0000 I think it is fine how it is, and we definitely don't want to use strings like "Platform".