RE: Exposing constructors of readonly interfaces to web authors

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan

> Are you saying we cannot have a WebIDL interface (DOMRectReadOnly) representing a "common base class" for DOMQuad.bounds rectangles and mutable DOMRects, because there are separate implementations with different internal state?

Right, exactly. I mean, you could make it work, but it would be very awkward---much more awkward than having no base class at all. In all designs I can see, you'd end up overwriting the getters that you inherited from the common base class, making the base class just a dummy. And you'd need three independent actors---the dummy base class that does nothing useful; the DOMQuadBounds class that overwrites all its base class getters; and the DOMRect class that also overrides all its base class getters.

(I'd be interested to be proved wrong, if you can draw up a JavaScript prototype where the base class design gives any benefit---even if just code reuse, which is generally not a great reason for inheritance, but is at least some reason.)

Remember that in JavaScript, inheritance hierarchies or don't actually buy you anything, since we don't have type checking to say "by taking a CommonBaseClass parameter, I am really saying I want to accept either a DOMQuadBounds instance or a MutableDOMRect instance." Instead what functions really should be saying is "I take anything with x, y, width, and height properties." (I believe there's no reason to require top/left/bottom/right properties in spec APIs.) In WebIDL this would be done with a dictionary argument; in JavaScript this would be done with destructuring arguments.

Received on Monday, 30 June 2014 03:19:35 UTC