Re: [PrototypeRoot]

On 6/20/09, Cameron McCormack <cam@mcc.id.au> wrote:
> Ian Hickson:
>> I don't really mind exactly what the solution is; my only concern here
>> would be that I'd be throwing [PrototypeRoot] around a lot.
>
> Acknowledged.  If you can propose a way of defining this without needing
> to use [PrototypeRoot] a lot, that’d help.
>
>> (I assume with PrototypeRoot that the most-derived interface that
>> inherits from such an interface is automatically promoted to being the
>> [[Class]]?)
>
> That’s right.
>

I still want to know: Why would a program want to know the object's [[Class]]?

Even if a program could know the [[Class]], what's to say it won't
change in the future?

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?

Microsoft has had vendor "extensions" in IE prior to the w3c dom level
1. Such vendor extensions don't fall nicely into type heirarchies, but
are well-suited towards mixin style design, which is possible with
interfaces.

Also, there will always be more browsers that implement an interface,
but don't give that object the [[Class]] property that is specified in
web IDL.

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 to using feature detection.

Even the [[Class]] were widespread-adopted, it would be a bad idea to
do that. I don't know what I am missing, but it doesn't seem to have
been explained on this thread.

Why do you want that?

Garrett

> --
> Cameron McCormack ≝ http://mcc.id.au/
>
>

Received on Saturday, 20 June 2009 07:36:01 UTC