W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

RE: Exposing constructors of readonly interfaces to web authors

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 27 Jun 2014 13:39:43 +0000
To: Anne van Kesteren <annevk@annevk.nl>, Dirk Schulze <dschulze@adobe.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <24dab6bc160f4db3a5a088917f587b50@BN1PR05MB325.namprd05.prod.outlook.com>
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.

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? 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.

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.)
Received on Friday, 27 June 2014 13:40:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC