Re: [PrototypeRoot]

On Sun, 21 Jun 2009, Garrett Smith wrote:
> 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.

Which part is untrue?

I said three things:

 - A program shouldn't want to know an object's [[Class]]
 - [[Class]] is exposed by ECMAScript in an object's toString() method
 - If we want to ensure universal behaviour we have to define this

You seem to agree with the second point, as you say:

> The [[Class]] property is exposed in Object.prototype.toString.

You presumably agree with the first point since you were asking for a 
reason and implying there wasn't one.

Do you disagree that we need to define things to get universal behaviour?


> Ensuring universally consistent behavior would require that *all 
> browsers* behave exactly the same.

Right, that's the goal.


> MSIE does not behave that way today and versions of other browsers may 
> vary, too.

Indeed, that's the problem we are trying to fix.


> 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.

As far as I can tell, everyone agrees that [[Class]] should be a string.


> The value of that string should be implementation-dependent.

That would not lead to a well-defined universal behaviour.


> 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).

It seems that the [[Class]] value has nothing to do with the flexibility, 
extensibility, and mixin style behaviour of objects.


> Providing a suggestion to implementors as to what that value might be 
> would be harmless.

And mostly useless, if they ignore it; if they don't, it might as well be 
a requirement.


> Mandating the *value* of that [[Class]] property creates a brittle, 
> fragile API.

It creates a well-defined, consistent and predictable API. This is 
desireable.


> 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.

I think it is woefully optimistic to expect any significant number of 
authors to read the specification.


> >> 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 specifications we write are the ones that are to say that it won't 
change. If the specifications say it changes, then it changes. My point is 
that it is up to the specifications we write to make this not 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.

So long as we converge on a stable and well-implemented platform, early 
changes are not a problem.


> >> 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.

It is no more or less brittle than anything else in the Web platform as 
far as I can tell. Any API could change; it is our responsibility to make 
sure that we don't change APIs that pages rely on.


> An object's [[Class]] feature should ideally provide specific, detailed 
> information, and should be used *only* in debugging. Never rely on it.

It would be wonderful if that were the case.


> >> 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.

Yup.


> We seem to be eye to eye on that much but I think the API design has 
> gone too far.

What API design?


> Defining the value of the [[Class]] encourages that value to be used in 
> code.

In practice, people are encouraged to use these features regardless of 
whether the specifications exist or not. For example, people use 
document.all even though it hasn't previously been specified, and they 
used it when only one browser supported it. Meanwhile there are plenty of 
specs that exist and are implemented that describe features that are used 
only in small amounts (relatively speaking). So I think it is clear that 
your statement here doesn't hold.


> 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

If we define a value and everyone implements it, then they will not blame 
anyone, for their code will work. I would rather do that than try to find 
a way to make them blame someone else.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 22 June 2009 23:49:58 UTC