RE: Exposing constructors of readonly interfaces to web authors

From: Rik Cabanier <cabanier@gmail.com>

> Sure. The thread is getting very fractured and I'm unsure what we're debating at this point. 
> I *think* we should mark the readonly classes as [NoInterfaceObject] or add constructor to them. Maybe we also should create dictionary representations so you can pass them to the DOM without type checking.

Heh. I agree about the thread.

I see several problems with the readonly class, at least in the DOMRect case:

- It is not constructable
- Its values can change through magic, but users cannot change them
- It is actually not solving the problem that it was meant to solve, namely being the bounds for a DOMQuad

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?

---

This was only focused around the DOMRect/DOMQuad case that has been discussed already. I am not sure what is the right solution for e.g. DOMPointReadOnly; it may be completely different (for example, creating a mechanism that allows the creator of the instance to modify it, but not consumers, like promises or revocable proxies). For now I cannot see any actual use cases for it, like the one that guided me to move DOMRectReadOnly to DOMQuadBounds, and so am not sure what approach is correct.

Received on Tuesday, 1 July 2014 20:30:33 UTC