- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 15 Jun 2012 17:27:03 -0400
- To: public-script-coord@w3.org
The actual behavior of implements statements seems to be somewhat underspecified to me. In particular, http://dev.w3.org/2006/webapi/WebIDL/#es-implements-statements says: The interface prototype object of an interface A MUST have a copy of each property that corresponds to one of the constants, attributes or operations that exist on all of the interface prototype objects of A’s consequential interfaces. and then the actual steps for calling a getter involve checking that O is "A platform object that implements an interface on which the attribute was declared". [Constructor()] interface A {}; [Constructor()] interface B {}; interface C { readonly attribute long foo; } A implements C; B implements C; and the following script: var b = new B(); b.__proto__ = A.prototype; b.foo; // Or grab the getter using getOwnPropertyDescriptor // and .call(), either way. Should this work? Quite honestly, my preference is that it should not, because otherwise each of the getters will have to know how to deal with all possible implementations of C. Similiarly, my preference is that the getter on C.prototype not work for instances of either A or B... Similar for setters and methods. Note that there are very few use-cases for this sort of thing, by the way. The one use case where people currently really want to .call or .apply DOM methods is when interposing their own thing on the prototype, and in the "implements" case they would have to do it on each prototype on the LHS separately anyway, right? On the other hand, having to support this sort of thing would significantly increase implementation complexity, I suspect. -Boris
Received on Friday, 15 June 2012 21:27:31 UTC