Re: [geometry] DOMQuad is weird

On Wed, Oct 19, 2016 at 12:00 PM, Simon Fraser <smfr@me.com> wrote:

> On Oct 19, 2016, at 11:37 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> On Tue, Oct 18, 2016 at 11:29 AM, Simon Fraser <smfr@me.com> wrote:
>
>> DOMQuad seems like the odd one out of the Geometry interfaces. It doesn’t
>> have a ReadOnly variant, and, unlike DOMRect, its points are 3D DOMPoints
>> (with x,y,w,z). In the WebKit implementation, we never have a need to store
>> quads in 3D space; they only ever exist in the plane of an element. We do
>> have code that tracks an accumulated matrix along with a planar quad when
>> mapping through 3D rendering contexts, but the quads are only ever used
>> once you flatten into the plane of an element.
>>
>> Also, I think [SameObject] readonly attribute DOMPoint cause unwanted
>> behavior for JS authors.
>>
>> Consider:
>>
>> var quad = DOMQuad.fromQuad({ p1:{ x:11, y:12 }, p2:{ x:22, y:23 }, p3:{
>> x:33, y:34 }, p4:{ x:44, y:45 } });
>>
>> var firstPoint = quad.p1;
>> firstPoint.x = 9999;
>>
>> if (quad.p1.x == 9999)
>>     console.log(“what the hey”); <— this happens
>>
>> I think it’s very counterintuitive for JS authors to have the points be
>> “live” if you pass them to other parts of the code and then modify them.
>>
>
> I don't understand why that would be counter-intuitive. Isn't this normal
> JavaScript behavior?
>
>
> As a naive JavaScript author, I would consider a point to be a primitive
> type that's copied by value.
>
> Dean points out that the primitive types are actually DOMPoint.x and
> DOMPoint.y, so what I wrote above is "expected" JS behavior.
>

I'm following. Are you agreeing that that having the live object is
expected?


> Having them be non-live would be "magic" because a DOMQuad is supposed to
> be a simple detached object.
>
>
> Maybe DOMQuad should be entirely read-only, or should return copies of
> points (getP1(), getP2() etc).
>

The spec calls out that you can change the value of the points:

The p1 attribute must return a DOMPoint
<https://drafts.fxtf.org/geometry/#dompoint> that represents p1
<https://drafts.fxtf.org/geometry/#dom-domquad-p1> of the quadrilateral it
was invoked on. The author can modify the returned DOMPoint
<https://drafts.fxtf.org/geometry/#dompoint> object, which directly affects
the quadrilateral.

so it seems that this was intended behavior.

Is this creating implementation problems for you?