Re: [PrototypeRoot]

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