Re: Exposing constructors of readonly interfaces to web authors

Lets take the example from DOMRectReadOnly again:

[NoInterface]
interface DOMRectReadOnly

and

function DOMQuad() {
	var rect = { x: 0, y: 0, width: 100, height: 100, top: 0, left: 0, bottom: 100, right: 100 }; // Or var rect = new DOMRect(…) if DOMRect is implemented.
	….

	var bounds_internal = {}; // Or var bounds_internal = new DOMRectReadOnly(); with function DOMRectReadOnly() { }
	Object.defineProperty(bounds_internal, 'x’, { get: function() { return rect.x; } });
	Object.defineProperty(bounds_internal, 'y’, { get: function() { return rect.y; } });
	Object.defineProperty(bounds_internal, 'width’, { get: function() { return rect.width; } });
	Object.defineProperty(bounds_internal, 'height’, { get: function() { return rect.height; } });
	Object.defineProperty(bounds_internal, 'top’, { get: function() { return rect.top; } });
	Object.defineProperty(bounds_internal, 'left’, { get: function() { return rect.left; } });
	Object.defineProperty(bounds_internal, 'bottom’, { get: function() { return rect.bottom; } });
	Object.defineProperty(bounds_internal, 'right’, { get: function() { return rect.right; } });

	this.bounds = bounds_internal;
}

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

This would obviously return [object Object]. Since DOMRectReadOnly is assumed to be a [NoInterfaceObject], this doesn’t even look wrong.

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

Not sure if that is correct. Please elaborate. The example above seems to fulfill the requirements of the IDL.

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

Just stick to the example of DOMRectReadOnly. That would make it much easier to follow the discussion.

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

The IDL has links to the description. Both, the readonly version and the mutable version are described by the same text. That the attribute can not be set if it is readonly can be deducted from the IDL and the WebIDL specification. To interpret it any different seems interesting. However, I take it as valuable feedback and add a description that the setter just applies if the attribute is not readonly.

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

Yes, this seems absolutely valid and can be implemented in JS as demonstrated by Rik and shown in the example above.

Greetings,
Dirk

Received on Saturday, 28 June 2014 11:39:39 UTC