- 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