Re: Exposing constructors of readonly interfaces to web authors

On Fri, Jun 27, 2014 at 6:39 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On
> Behalf Of Anne van Kesteren
>
> > The way Domenic explained this the last time around was that certain
> constructors would accept an ID of sorts as argument that only the UA would
> know about.
>
> > Given that explanation, I don't see the problem throwing for these
> constructors, just like we throw for
>
> >> new Navigator
> >> new Window
>
> To be clear, here is the code you would have to write to explain this in
> JavaScript:
>
> ```js
> var unguessableSecret = generateSecret();
>
> class DOMRectReadOnly {
>   constructor(x, y, width, height, secret) {
>     if (secret !== unguessableSecret) {
>       throw new TypeError("Only UAs can construct DOMRectReadOnlys!");
>     }
>     ....
>   }
>
>   get x() { ... }
>   ...
> }
> ```
> But this is just silly in the case of DOMRectReadOnly and friends. There
> is no magic data, like a browser-internal representation of a window or
> navigator, or of a crypto algorithm (see
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-CryptoKey-slot-handle),
> which cannot be used by a user. You are instead just artificially limiting
> users for no good reason, by not giving them the unguessable secret.
>

The ReadOnly interface names should not be exposed to the user. I think
this is a oversight in the spec and we should put [NoInterfaceObject] on
them.
Instead, the conceptual model is that method that returns a readonly object
does the following:

function getMatrix() {

var retval = { m11: 5, m12: 6, .... };

Object,DefineAttribute(retval, "a", function() { retval.m11;}).

retval.translate = function(...){...};
...

return retval;

}

FWIW Cameron told me that an author could create these readonly objects
without having the instantiate a full mutable object.
If there's a DOM method that takes a DOMPointReadOnly, he could write:

Translate({x: 2, y: 5, z:0, w:1});

Maybe he can fill in how that works.

This has no benefits, since it does not enable implementations to do
> anything special with e.g. object layout or tying it to special object
> pointers. It has only downsides.
>
> From: Dirk Schulze [mailto:dschulze@adobe.com]
>
> > My concern is that we expose functionality that might not be used by
> authors (creating a readonly object that even the creator can not modify).
>
> Why is the DOM creating a readonly object that even the DOM cannot modify?
> Or is the DOM somehow able to modify these objects?


The ReadOnly object are indeed designed to be live. For instance, you can
hold on to the matrix of an SVG element [1] and look at its changes.
SVG had big problem with return live, *modifiable* objects and we want to
avoid repeating that mistake.


> I notice that despite there being no setter for x, y, width, and height,
> the spec says things like
>
> "The x attribute, on setting, must set the x coordinate to the new value."
>
> Since you can't set a readonly attribute, this is just a bug in the spec
> as it stands.
>

Can you point to where in the spec that is stated? I can only find the
setter language for DOMPoint which is not read-only.


> The question is whether the intention was to allow the DOM to modify the
> object, in which case they would do so via mutable internal slots that the
> x, y, width, and height public getters return the value of, or whether the
> intention was for these objects to be immutable after creation. (Again, for
> an excellent example of this, see WebCrypto, e.g.
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#cryptokey-interface-members
> where the getters are specified.)
>

I don't see the language in that spec to be all that different.
Do you prefer that we use "reflect" instead of "correspond"?

1: http://www.w3.org/TR/SVG/coords.html#__svg__SVGTransform__matrix