Re: Figuring out easier readonly interfaces

On Oct 3, 2013, at 6:17 AM, Mark S. Miller wrote:

> On Thu, Oct 3, 2013 at 5:50 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> I agree with Mark. There is no way to automatically derive the read-only version of an interface. So at least we'd need per-member annotations that describe how to a readonly<Foo> is related to a Foo.
> 
> The approach I'm pushing for DOMRect in www-style seems much simpler to me: have (conceptually) three separate interfaces:
> -- DOMRectReadOnly: an interface exposing read-only accessors to the current state of a DOMRect. Nothing is said about whether the object is mutable or not.
> -- DOMRect: a subinterface of DOMRectReadOnly, exposing mutating APIs.
> -- DOMRectImmutable: a subinterface of DOMRectReadOnly, which guarantees that the state never changes.
> This approach satisfies the LSP. There's minimal duplication of methods/attributes. It works well in WebIDL since WebIDL already allows attributes to be readonly in DOMRectReadOnly and writable in DOMRect. (In this specific example we don't need DOMRectImmutable right now so we won't define it.) What's not to like? :-)

Well a; subclass (subtype) in this concept is a specialization of a more general concept. It adds an additional capability that isn't present in the more general abstraction. In this case the specializations we are adding are the ability to change the coordinates of a rectangle or the assurance that the coordinates will not observably change.

From that perspective, I would name the most general concept:

DOMRect  -- it encompass all rectangle used by the DOM
DOMVarRec  -- it specializes DOMRect by adding the ability to vary its coordinates.
DOMImmutableRec  It never changes

Allen