RE: Exposing constructors of readonly interfaces to web authors

From: Rik Cabanier [mailto:cabanier@gmail.com] 

> function getMatrix() {
> var retval = { m11: 5, m12: 6, .... };
> Object,DefineAttribute(retval, "a", function() { retval.m11;}).
> retval.translate = function(...){...};
> ...
> return retval;
> }

This is not valid JavaScript, which is worrying, but we can assume you meant to define a getter.

Regardless, it has completely different semantics from those specified in the spec. For example in this version, 'a' is an own-property, whereas in the spec, it is on the prototype. As such the getters, as well as the translate method, are different for every instance returned from the getMatrix() method, and don't end up on a common prototype that can be inspected via Object.getPrototypeOf(getMatrix()).

So this is not at all a tenable explanation of the semantics you are creating.

It is extremely important that you understand how to manifest the semantics of your specification in JavaScript, as without that kind of understanding, authors are hurt by the un-idiomatic nature of the exposed API; polyfillers are hurt by the fact that such APIs are impossible to polyfill; and implementers are hurt because they cannot self-host. WebIDL has a number of very bad defaults (like no constructor, by default) which presumably stem from its legacy in OMGIDL, and can lead you down the wrong path. The purpose of reviews such as this is to help avoid these pitfalls, and gather data so we (the TAG) can write up guidance documents so that editors don't run in to them in the future.

> 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});

It's not clear how this would work; I am very curious. Since, for example, you can't actually create DOMPointReadOnly instances, so there's no way for a method to convert such an object into a DOMPointReadOnly instance, since no instances of DOMPointReadOnly can actually exist in JavaScript. Perhaps you are using the unguessable-secret technique, but I see no such language in the spec to enable that.

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

In http://dev.w3.org/fxtf/geometry/#DOMPoint, http://dev.w3.org/fxtf/geometry/#DOMRect, etc. the language appears for "the x attribute..." etc. If you are saying that those descriptions only apply to one of the two classes defined in each section, then that is not clear at all, and furthermore if that's the case, then the read-only versions have no behavior specified and could return any value at all for their attributes (i.e. there is no specification text saying that they return coordinates).

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

The key difference is that they separate mutable internal slots from public getters which return the current value of the mutable internal slot. The geometry spec has no such distinction: it has properties that only have getters, but somehow their values change.

Received on Saturday, 28 June 2014 08:17:47 UTC