In a JavaScript library (Node and browser) to which I am contributing (IndexedDBShim), for the sake of complete test coverage, I am hoping to ensure we can not only better pass general W3C tests pertaining to IndexedDB, but also the WebIDL-based interface tests related to IndexedDB.
In preparation for this, when I run the WebIDL tests of the W3C over the Event
and CustomEvent
interfaces with the Event polyfills we are using, one testing requirement that becomes evident after parsing interface CustomEvent : Event
is that the prototype of CustomEvent
must be set to Event
. Please note that I am not referring to any requirement that the prototype of CustomEvent
objects must inherit from Event
(ala CustomEvent.prototype = new Event();
or CustomEvent.prototype = Object.create(Event);
), mind you, but that the prototype of the object responsible for the class (the constructor function CustomEvent
) is set to Event
rather than as the default, Function.prototype
).
Sure enough, in Chrome's console, I see that for the built-in interfaces, Object.getPrototypeOf(CustomEvent) === Event
is indeed true
. As far as I can tell, the only (standards-based) way I can get this to occur in a polyfill is to do the following:
function ShimEvent () {}
function ShimCustomEvent () {}
Object.setPrototypeOf(ShimCustomEvent, ShimEvent);
...but I see warnings on MDN that this method is slow across all browsers.
I guess I will just need to choose on whether the performance hit is worth the greater standards-compliance.
However, in any case, I'd still like to have a better understanding to know of what consequence it is for interfaces to inherit in this manner (and perhaps this is more a question of my understanding of JavaScript rather than of WebIDL per se).
Since by the fact of such a mere association between the function object prototype's, the methods of the inheriting interface do not get inherited by the base interface, is the expectation of a prototype connection between the class functions to merely express the inheritance hierarchy between the interfaces for the sake of any who might wish to introspect on them within code? Or is there some other practical consequence to this particular requirement of a class prototype connection?