Re: Exposing constructors of readonly interfaces to web authors

On Jul 9, 2014, at 4:54 AM, Domenic Denicola <domenic@domenicdenicola.com> wrote:

> From: Rik Cabanier <cabanier@gmail.com>
> 
>> This confirms that the current behavior can be implemented using JavaScript.
>> Doesn't this satisfy Domenic's requirement?
> 
> It does, indeed, and gives us a path forward. However, in doing so, it points out that what the spec specifies is nowhere close to what was implemented. Here is a sketch of how we could update the specification to match what is (observably) going on:
> 
> - 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

I updated DOMRect, DOMRectReadOnly and DOMQuad and addressed the feedback for these three interfaces you gave.

* DOMRectReadOnly has a constructor.
* DOMRect constructors call the constructor of DOMRectReadOnly.
* DOMQuad constructor takes an DOMRectInit instead of a DOMRectReadOnly as argument.
* The prose indicates implies internal member variables that are not directly exposed. DOMRect and DOMRectReadOnly have read/write access to the vales of these variables.
* Other interfaces may have write access to these internal member variable values as well. The interface must explicitly state this.
* Getter and setter descriptions are more explicit.

Please review the changes here[1] and provide feedback.

I’ll update the other interfaces once we agreed on the behavior for DOMRectReadOnly.

Greetings,
Dirk

[1] http://dev.w3.org/fxtf/geometry/#DOMRect

> 
> 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?

Received on Tuesday, 15 July 2014 11:23:36 UTC