RE: Exposing constructors of readonly interfaces to web authors

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan

> It seems to me this rule would imply we shouldn't have "Element implements GeometryUtils" and "Text implements GeometryUtils", and instead we'd simply duplicate the APIs on those interfaces, since they're implemented separately, and rely on editor vigilance to keep their specs in sync. It seems to me this rule prohibits almost any use of the WebIDL "implements" feature. Is that right?

Nope. The implements feature is like a spec-level macro that mixes in the given components. It does not set up an actual JavaScript-visible inheritance hierarchy like you are talking about in the preceding messages. Unless I misunderstood, and when you said base class, you did not mean JavaScript base class?

It's an excellent WebIDL feature, by the way. It's important that WebIDL be able to express these kinds of things declaratively, whereas in JS they would be done via `Object.mixin(Class1.prototype, mixinProto)` plus `Object.mixin(Class2.prototype, mixinProto)`, which is far too imperative for a definition language. But I don't think implements has anything to do with what you are proposing, unless we are talking past each other massively.

> Those properties are needed for compatibility reasons: DOMRect is an evolution of ClientRect, which dates back to IE6 and has those properties. They are also useful in their own right since we decided not to enforce the invariant that width/height are non-negative.

You're misunderstanding me. What I meant was, when taking as input an object to a spec algorithm, you should not say "it must be a DOMRect" (or ClientRect, or DOMRectReadOnly, or CommonSuperclassRect, or...). You should say "it has x, y, width, height properties." That has nothing to do with its class.

When talking about the outputs of spec algorithms, nicely-designed classes are great! But as such, the inheritance hierarchy you are proposing is not useful, since they don't provide any type-checking on the input side, and the base class is never actually vended by anyone on the output side. You might as well just have the two output-side classes, since they will have different algorithms for their "left" property in each case. (Viz., `return min(this.x, this.x - this.width)` versus `return min(this.q.x1, this.q.x2, this.q.x3, this.q.x4)`) That was what I was trying to get across.

> It seems to me you're taking the position that because JS currently has no good way to express subtyping relationships, WebIDL shouldn't either. If that's your position, I disagree with it strongly.

Nope, that's not what I'm saying. I'm saying that when you create an user-exposed inheritance hierarchy in JS, it should be actually useful. Having a base class whose members are overwritten by every single subclass buys you nothing---not at a spec level, not at a user-facing level, and not at a conceptual level.

Received on Monday, 30 June 2014 04:54:52 UTC