Re: [fxtf-drafts] [geometry] Why does DOMQuad have readonly mutable points?

I agree with @zcorpan that simply removing `readonly` would create some API inconsistencies. If one wants to assign `DOMPointInit` then he/she needs to create a new `DOMQuad`. So in this case I rather would like to add setters than dropping the `readonly` notation. I can't recall why right now but I am pretty sure that we added `readonly` on request because we had to.

To the point of "magic" from @cabanier on the mailing list: I think what Rik is referring to is the request from @domenic et al. to make the spec "implementable in script". Usually, a property on an object with an object assigned to it returns a reference to that object. Which is a different behavior than the requested change here (new object). If my understanding of Riks concern is correct, then this does not apply here though.

Adding `DOMQuadReadOnly` would be consistent with `DOMPointReadOnly` and `DOMRectReadOnly` but we only added those for backwards compatibility reasons to SVG. Adding it deliberately does not seem to be the right way forward to me. So far we didn't hear an actual use case for `DOMQuadReadOnly` by itself and it could add additional implementation burden and maybe even (though unlikely) performance penalties.

@tabatkins (as Blink representative and the one raising the issue here) @smfr @bzbarsky As @zcorpan said: If you are willing to change the currently interoperable implementations to return new objects rather than references we can change the spec.

-- 
GitHub Notification of comment by dirkschulze
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/124#issuecomment-382187598 using your GitHub account

Received on Tuesday, 17 April 2018 23:17:27 UTC