Re: [WebIDL] prototype chains, multiple inheritance, mixin interfaces

On Nov 23, 2010, at 4:12 AM, Andrew Oakley wrote:

> Because it is not possible to get an objects prototype (except for with
> the completely non-standard, deprecated property __proto__),

This is not true: ES5 has Object.getPrototypeOf(obj), equivalent to reading obj.__proto__.


> and the
> WebIDL specification does not specify any odering we can inherit from
> whatever we like without issue, as long as we have a sensible resolution
> order (C3) and [[HasInstance]] implementation.

Total order must be normative for a given set of interfaces -- JS developers can and do come to depend on details of ordering (e.g. HTMLDivElement.prototype customizations in the current WebKit DOM do not work as expected in recent Gecko DOM versions).

All abstractions leak on the web, which does use __proto__ if it's there and which is starting to use Object.getPrototypeOf. Even without these reflection APIs, prototype relationships can be discovered by overriding, shadowing, and observing.


> * We can use the same mechanism to make the global inherit from both
> Window.prototype and the ECMAScript global object.

The ECMAScript global object is not on the prototype chain of some other (Window) really-global object. The two are the same (which means Window must not be a "host object" in ES5 terms; see 8.6.2). ECMA-262 requires builtins such as parseInt and eval to be "own" properties of the global object (|this| in global code, AKA |window| and |self| in browsers).


> On a positive note we actually use
> the same implementation for all objects in the system - the behaviour is
> not changed for objects with single inheritance.

How do you implement ES5's Object.getPrototypeOf? There must be some overhead in mapping the MI in your "objects in the system" onto the C3-linearized chains of JS objects reflecting those native objects. Linearization is not free in light of Object.getPrototypeOf.

This is a trade-off. It can matter for code size and performance. It also matters for non-JS bindings, e.g. Java and C++, as noted in this thread.


> Is this a reasonable way of dealing with the problem?  Are there any
> issues with doing this?  Is it any better than the proposal from the
> TC39 meeting?

C3 is reasonable in my opinion, but it's strictly more complicated than single inheritance with mixins implemented by "copying" (or as if they are macros). If JS developers do not need reified mixin interfaces with .prototype properties, then simpler wins. That was our judgment last week at the TC39 meeting.

We were hard pressed to find abstract or mixin interfaces that needed to be reflected into JS. EventTarget is moving up to be a common prototype in the DOM hierarchy. Other examples showed up as types of parameters in WebIDL and bindings for languages such as Java, but not in JS.

Did we miss something?

/be

Received on Tuesday, 23 November 2010 18:48:26 UTC