Re: Exposing constructors of readonly interfaces to web authors

On Mon, Jun 30, 2014 at 3:18 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> 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.)
>

Various people, for example myself and Hixie, have hitherto believed
extracting common API into shared superinterfaces is generally a good
thing, because it reduces duplication of spec text and increases the
likelihood that specs for objects with common functionality will evolve in
sync, even if there is little or no sharing at the implementation level. So
I'm surprised to hear that this is now banned.

It seems to me this rule would imply we shouldn't have "Element implements
GeometryUtils" and "Text implements GeometryUtils", and instead we'd simply
duplicate the APIs on those interfaces, since they're implemented
separately, and rely on editor vigilance to keep their specs in sync. It
seems to me this rule prohibits almost any use of the WebIDL "implements"
feature. Is that right?

I'm suspicious of making spec structure dependent on assumptions about how
much sharing there will be between different implementations of an
interface. These implementation decisions can be difficult to predict, they
can change over time, they can differ between implementations, and isn't
the point of specs to be independent of such decisions?

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.)


Those properties are needed for compatibility reasons: DOMRect is an
evolution of ClientRect, which dates back to IE6 and has those properties.
They are also useful in their own right since we decided not to enforce the
invariant that width/height are non-negative.

It seems to me you're taking the position that because JS currently has no
good way to express subtyping relationships, WebIDL shouldn't either. If
that's your position, I disagree with it strongly.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w