Re: Exposing constructors of readonly interfaces to web authors

On Wed, Jul 9, 2014 at 2:54 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> - DOMRectReadOnly contains a [[type]] internal slot, which is either
> "quadbounds" or "rect"
> - The x getter on DOMRectReadOnly returns either [[x]] if [[type]] is
> "rect", or the minimum of q.p1.x, q.p2.x, q.p3.x, and q.p4.x if [[type]] is
> "quadbounds". Similarly for y, width, and height.
> - DOMRectReadOnly's constructor then needs to have two different behaviors
> (which could be based on arguments, or on e.g. the first parameter): one
> that sets the [[type]] slot to "quadbounds" and the [[quad]] slot to the
> given quad, and one that sets the [[type]] to "rect" and sets the [[x]],
> [[y]], [[width]], and [[height]] slots.
> - DOMRect derives from DOMRectReadOnly.
>   - It has a single constructor, (x, y, width, height), which calls
> super(x, y, width, height) (or super("rect", x, y, width, height), perhaps).
>   - It has its own getters and setters for manipulating [[x]], [[y]],
> [[width]], and [[height]].
>   - Thus DOMRects will always have [[type]] "rect", which means that you
> can successfully apply DOMRectReadOnly's getters to it, as you would expect
> for an inheritance situation.
>
> I sketched this up, in a similar fashion to the previous one:
> https://gist.github.com/domenic/60871738e49a2b8c7a01
>
> If this looks kind of weird, that's because it is. In general JS
> programmers would not write code this way. But, we are trying to meet many
> constraints here that JS programmers would not normally attempt, e.g.
> readonly views, reusing the same code for both live quad-bounds and
> one-time readonly snapshots, having a common prototype that can be
> monkeypatched by user code, and the like.
>
> This seems to address Roc's concerns, though, and at least it is something
> that can be implemented (and introspected) in JavaScript.
>
> All righty then, what do we think this time around?
>

I don't object to it. Thanks for working this out.

But it still feels to me like it exposes far more implementation details in
the spec than necessary. It seems to me the observable invariants around
prototypes and method identity can be succinctly expressed by saying that
DOMQuad.bounds returns an object whose prototype is DOMRectReadOnly, and
everything else follows from WebIDL.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.