Re: Exposing constructors of readonly interfaces to web authors

On Fri, Jun 27, 2014 at 9:35 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> 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;
>
> }
>
>
After sending this out, I realized that there was a typo.
Here's the correction for a function that return a readonly interface of
DOMMatrix:

getMatrix: function(){

var retval = {};
Object.DefineAttribute(retval, "a", { get: function() { return
this.m11_equivalent; } });
...
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
>