Re: Prototype chain for objects that implement multiple interfaces

Cameron McCormack:
> >  NodeList = { an object }
> >  NodeList.[[Prototype]] = Object prototype object
> >  NodeList.prototype = { an object }
> >  NodeList.prototype.[[Prototype]] = Object prototype object
> >  NodeList.prototype.constructor = NodeList
> >  NodeList.prototype.someFunction = { some function }

liorean:
> Well, if there is no [[Construct]] property on the NodeList that is
> callable using
>    new NodeList
> I don't think the NodeList.prototype.constructor property should point
> to the NodeList object. If there is a constructor that is callable in
> that way then let it point there. If there is no such constructor then
> there should not be a NodeList.prototype.constructor property.

That’s probably fair.  Mozilla does have a constructor property, but the
other browsers I tested don’t.

> Also I think you forgot two things:
>    NodeList.[[Class]] = "Object"
>    NodeList.prototype.[[Class]] = "NodeList"
> 
> (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.)

Not interoperable because IE probably won’t change their implementation
to work this way, or because most browsers won’t?

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.

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

> > Any opinions on how to specify this?
>
> I'd wish to say I had a reasonable opinion. I do have an idea about it
> that is very similar to yours, but that would require a chaining
> together of prototype chains, which likely would mean that the
> multiple multilevel inheritance problem would have to be solved. I
> doubt we'd want to go into that. But if we indeed do want to go into
> that, the Python model makes best sense of all I've see so far. Just
> use it for prototypes instead of classes. The inheritance list itself
> doesn't have to be runtime resolved since it only applies to the DOM
> and not any ES objects, implementations would probably hardcode it for
> performance reasons.
> <uri:http://www.python.org/download/releases/2.3/mro/>

Thanks for the link. 

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Wednesday, 6 June 2007 12:12:45 UTC