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: Mon, 30 Jun 2014 02:33:10 +0000
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <10d6560b4c2842e6985bbd477077db71@BN1PR05MB325.namprd05.prod.outlook.com>
From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan

> It seems to me that it is simpler, more predictable and more efficient to have b1 === b2 hold independent of what doAnythingAtAll does.

Sure, that's fine, as long as this is done in such a way that the semantics can actually be implemented in JavaScript (e.g. similar to how you show in your message, but not similar to how it works in the spec).

> I was under the impression that WebIDL interfaces are, well, *interfaces* --- that they don't need to describe all internal state.

First, WebIDL interfaces are misnamed; they should be named "classes" or even "constructors," since that is what they correspond to in JavaScript. The only reason we haven't changed it is because such cosmetic tweaks force everyone to update their IDL for no normative benefit. That said, the confusion caused by the existing WebIDL terminology is very real, as we are seeing in this thread. (Similarly, what they correspond to in JavaScript is all that matters, despite the confusion caused by the "JavaScript bindings" language; we also saw that in this thread.)

Second, internal state needs to be specified, even if it's not in the WebIDL. In particular, saying "returns min(the x coordinate, the x coordinate + the width)" is *not* the same as "returns min(this.q.x1, this.q.x2, this.q.x3, this.q.x4)". This is why I was referring to the web crypto spec earlier; it does an *excellent* job of specifying internal state, and in particular how the getters exposed by each class relate to that internal state.

Third, since WebIDL interfaces correspond to concrete JavaScript classes directly, it's not possible for one instance of the class to have internal state linked to a quad, and another to have... some other, different internal state, not related to a quad. This is why the version in your message was so promising, because it reflected the actual usage (being linked to a quad, through the public `q` data property) instead of trying and failing to be a generic read-only rectangle class that can never be constructed and has properties that return "the x coordinate" and similar phrases.
Received on Monday, 30 June 2014 02:33:45 UTC

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