- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Sun, 21 Jun 2009 18:31:19 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: WebApps WG <public-webapps@w3.org>
On Sat, Jun 20, 2009 at 12:43 AM, Ian Hickson<ian@hixie.ch> wrote: > On Sat, 20 Jun 2009, Garrett Smith wrote: >> >> I still want to know: Why would a program want to know the object's >> [[Class]]? > > It shouldn't, but [[Class]]es are exposed by ECMAScript objects in their > toString() method and thus if we want to ensure universally consistent > behaviour we have to define this. > No, that is all untrue. The [[Class]] property is exposed in Object.prototype.toString. Ensuring universally consistent behavior would require that *all browsers* behave exactly the same. MSIE does not behave that way today and versions of other browsers may vary, too. To ensure safer, more reliable behavior, define the [[Class]] property as being a string value. That way, it would be guaranteed that Object.prototype.toString.call( any_object ); would result in string value being produced, and an error would not occur. The value of that string should be implementation-dependent. This makes the feature flexible, extensible, and provides the aforementioned benefits of interfaces over classes (e.g. mixin style behavior with implementation-specific host objects). Providing a suggestion to implementors as to what that value might be would be harmless. Mandating the *value* of that [[Class]] property creates a brittle, fragile API. Authors will utilize the specification to write code to that value to create code that is as brittle and fragile as the API it uses and works in fewer implementations, including browsers that are in widespread use today. > >> Even if a program could know the [[Class]], what's to say it won't >> change in the future? > > The specs we write. No, the specifications do change. The introduction of "HTMLFormControls" collection, for example, was a new one. There is a possibility of a "StaticNodeList" or "HTMLLinks" collection in the future. The interfaces implemented by an object vary between implementations and evolve over time. > > >> Given a particular object, can that object's [[Class]] property change >> in the future? If it there is an object that exists, say, some sort of >> HTMLCollection, and it becomes desirable to make more specific behavior, >> say "HTMLFormControlsCollection", what would the code that expects the >> object's class to be HTMLCollection need to do to continue working in >> multiple versions of multiple browsers? > > We would have to test to see if any pages rely on it; if they do, we'd > have to make sure we don't change the [[Class]] somehow. That sounds like a brittle feature. An object's [[Class]] feature should ideally provide specific, detailed information, and should be used *only* in debugging. Never rely on it. > > >> Given all these reasons, it would still seem like a bad idea to program >> to an object's [[Class]]. Instead, the interface should be programmed tot >> using feature detection. > > Yup. > OK. Strings are not a substitute for capability checks. The [[Class]] in particular has very little potential to return information about what an object can do. It would be a very risky design decision to make inferences solely on the [[Class]] value. We seem to be eye to eye on that much but I think the API design has gone too far. Defining the value of the [[Class]] encourages that value to be used in code. That is bad! Programmers who rely on that value will not rightly blame themselves for their design mistakes. Instead, they will look externally, read the standard, and blame the implementations that don't do what their perfectly standards-compliant program expects Garrett
Received on Monday, 22 June 2009 01:31:55 UTC