Re: Prototype chain for objects that implement multiple interfaces

> liorean:
> > (The ECMAScript built-in constructors all follow the pattern of having
> > [[Call]], so their [[Class]] is "Function" instead and their
> > [[Prototype]] is the initial Function.prototype. The DOM constructors
> > don't have [[Call]] so their [[Class]] should be "Object" instead. Or
> > some implementation specific value, but if we're specifying things
> > that are not interoperable anyway I think we can at least do the
> > sensible thing.)

On 06/06/07, Cameron McCormack <cam@mcc.id.au> wrote:
> Not interoperable because IE probably won't change their implementation
> to work this way, or because most browsers won't?

Actually Trident seems to use Object consistently for COM objects
(even function objects). For example:

    Object.prototype.toString.call(document.prototype).slice(8,-1);
    Object.prototype.toString.call(document.getElementById).slice(8,-1);

Also, just in this particular case, try these:
   Object.prototype.toString.call(Node).slice(8,-1);
   Object.prototype.toString.call(Node.prototype).slice(8,-1);

For the interface object Gecko gives "Constructor", Presto gives
"Node", WebKit gives "NodeConstructor" (in saf 1.3 since I'm still
running Panther) and Trident doesn't have a Node interface object. For
the interface object prototype Gecko gives "DOM
Constructor.prototype", Presto gives "Object", WebKit  gives "Window".
So I literally mean that there is no interoperability right now. You'd
have to fork for every browser if you wanted  to write code that
depended on the value of [[Class]] for interface objects or interface
object prototypes.

On 06/06/07, Cameron McCormack <cam@mcc.id.au> wrote:
> I would be happy to leave those [[Class]] properties implementation
> specific, unless someone can come up with a reason it'd be useful to
> have them standardised.

The only reason I can think of to standardise them would be that it
makes debugging easier the more specific they are.

On 06/06/07, Cameron McCormack <cam@mcc.id.au> wrote:
> If they were to be specified though, I'd argue though that the interface
> prototype objects needn't have their [[Class]] set to the interface
> name, as the built-in ECMAScript constructors' prototype objects do.

I don't have a particular opinion on whether "Object" or some
implementation specific value is better for interface objects. I do
think the interface object prototypes should have the same value for
[[Class]] as their instances, and that instances should have the value
for [[Class]] being their primary interface name.

On 06/06/07, Cameron McCormack <cam@mcc.id.au> wrote:
> For the built-in constructors, their prototype objects are actually
> instances of the class themselves.  I don't know that it would make
> sense here to have, for example, a Node instance as the Node interface
> prototype object.  Thus I'd be happy with "Object".

Actually, not a single one of the ECMAScript prototypes is an instance
of the type it's the prototype of, they are just very close to being
that. The reason for this should be obvious: If they indeed were
instances their prototype chain would loop back to themselves and
would never go back all the way to the Object prototype. Instead they
are defined to be equivalent of some basic "empty" instance of the
type, having all properties of the instances but with a [[Prototype]]
of the Object prototype.

RegExp and NativeErrors are the exceptions to this rule in the ES3
standard, these have prototypes whose [[Class]] should be "Object" and
"Error" respectively. RegExp.prototype.[[Class]] in browsers does not
follow ES3, though. Gecko, Presto and Trident use "RegExp", WebKit
uses "RegExpPrototype".
-- 
David "liorean" Andersson

Received on Wednesday, 6 June 2007 13:59:18 UTC