- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Thu, 11 Apr 2013 12:24:10 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: public-webapps@w3.org, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Apr 11, 2013, at 12:04 PM, Boris Zbarsky wrote: > On 4/11/13 12:55 PM, Boris Zbarsky wrote: >> On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote: >>> Yes ES6 has "class-side" inheritance >> >> OK. Should we be doing that with WebIDL interface objects, perhaps? It >> would certainly make sense to me to do that, as long we we don't run >> into web compat issues. > > I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=860841 with a patch to do this. The specific behavior I'm implementing is that the prototype of the interface object for interface X is the interface object of the nearest ancestor of X that has one, and Function.prototype if there is no such ancestor. > > So for example, with that patch Object.getPrototypeOf(HTMLElement) == Element, and Object.getPrototypeOf(XMLHttpRequest) == EventTarget. > > Note that this doesn't quite match the proto chain, because Object.getPrototypeOf(XMLHttpRequest.prototype) is the prototype object for the XMLHttpRequestEventTarget interface, but that interface is [NoInterfaceObject]. > > -Boris > That sounds about right. In ES6 you will still be able to wire-up arbitrary [[Prototype]] chains on both the instance and constructor-side using Object.create, __proto__ (now part of the standard), and ossibly crazy things via Proxy. But the most concise way to define class-like abstractions is going to be via class declaration. It seem quite desirable that the "normal" case for such abstractions specified via WebIDL is that they simply follow the ES6 class pattern. Exceptions are fine for legacy or special circumstances. Allen
Received on Thursday, 11 April 2013 19:24:41 UTC