Re: Exposing constructors of readonly interfaces to web authors

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

> From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of
> Robert O'Callahan
>
> > 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?
>
> Nope. The implements feature is like a spec-level macro that mixes in the
> given components. It does not set up an actual JavaScript-visible
> inheritance hierarchy like you are talking about in the preceding messages.
> Unless I misunderstood, and when you said base class, you did not mean
> JavaScript base class?
>

No, you're right.

You're misunderstanding me. What I meant was, when taking as input an
> object to a spec algorithm, you should not say "it must be a DOMRect" (or
> ClientRect, or DOMRectReadOnly, or CommonSuperclassRect, or...). You should
> say "it has x, y, width, height properties." That has nothing to do with
> its class.
>

I guess we would do that. Currently nothing takes a DOMRect(ReadOnly) as an
input, so this hasn't come up.

When talking about the outputs of spec algorithms, nicely-designed classes
> are great! But as such, the inheritance hierarchy you are proposing is not
> useful, since they don't provide any type-checking on the input side, and
> the base class is never actually vended by anyone on the output side. You
> might as well just have the two output-side classes, since they will have
> different algorithms for their "left" property in each case. (Viz., `return
> min(this.x, this.x - this.width)` versus `return min(this.q.x1, this.q.x2,
> this.q.x3, this.q.x4)`) That was what I was trying to get across.
>

The Gecko implementation actually shares a common implementation of
left/top/right/bottom across DOMQuad.bounds and DOMRect, defining them in
terms of x/y/width/height which are delegated to the concrete subclasses.
That's not too surprising since DOMRectReadOnly has invariants common
across the subclasses, such as left = min(x, x + width). It's easy to
imagine extending DOMRectReadOnly with more functionality common to the
subclasses, e.g. area(), contains(point), intersects(rect).

> 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.
>
> Nope, that's not what I'm saying.
>

Good :-).

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