Re: Exposing constructors of readonly interfaces to web authors

On Wed, Jul 2, 2014 at 8:29 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> Roc's earlier message hinted at a way out of the latter. In the interest
> of being constructive and making some more actionable suggestions in this
> thread, here is a draft of what I think would solve both problems while
> maintaining (as far as I can tell) the desired properties of a solution:
>
> https://gist.github.com/domenic/8f96ca2eccff5df951ef
>

> Notably:
>
> - DOMRect is a mutable DOMRect that can be used  for whatever.
> - DOMQuadBounds serves as the bounds for a quad.
> - DOMRectUtils gives you the top/right/bottom/left utilities, as well as a
> place to put future rect-related utilities, and is implemented by (but not
> inherited from) DOMRect and DOMQuadBounds.
>
> What do you think?
>

Thanks.

That's not bad but it seems like a regression from the current spec in a
few ways:
1) Web authors can't extend DOMRectUtils with new methods in one place.
They'd have to add new methods to both DOMQuadBounds.prototype and
DOMRect.prototype. In the current spec, they only have to add methods to
DOMRectReadOnly.
2) In practice, exposing DOMQuadBounds seems unnecessary. The only thing it
provides that the current spec does not is the ability for authors to
construct a DOMQuadBounds of a non-DOMQuad JS object. But it's unclear
whether anyone wants that, and it adds significant complexity to the
browser implementation of DOMQuadBounds. In fact I can't think of anything
like this (a DOM object that wraps a JS object) in the Web platform today.
3) There is nothing to keep DOMRect and DOMQuadBounds consistent in the
syntax and semantics of their common members other than editor vigilance.
Nothing even states what consistency is required.
4) Problems 1 through 3 get worse every time we add a new
browser-implemented read-only rectangle view, e.g. if we add
DOMPolygon.bounds or Canvas2DPath.bounds.

I'd like to push a little more against the requirement that every host
object class have a corresponding WebIDL interface. That seems to require
spec work and API maintenance for no author benefit, as well as making
specs improperly dependent on implementation details (that could
legitimately vary across implementations).

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