W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

Re: Figuring out easier readonly interfaces

From: Mark S. Miller <erights@google.com>
Date: Thu, 3 Oct 2013 13:55:31 -0700
Message-ID: <CABHxS9j_HshM-sHBL1cxpk+ACf91eKhvcihrLYtGJxCWEE=yBQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, "Robert O'Callahan" <robert@ocallahan.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
You lose the inability to mutate. If this inability to mutate was not part
of the intended contract of the superclass, it should not use the term
"read only".


On Thu, Oct 3, 2013 at 1:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Oct 3, 2013 at 12:33 PM, Mark S. Miller <erights@google.com>
> wrote:
> > You forgot to name the readonly one -- it specializes DOMRect by
> > guaranteeing that its instances not provide the ability to mutate the
> > underlying DOMRect. Given the other names, DOMRectReadOnly or
> DOMReadOnlyRec
> > (did you really mean to omit the "t"?) seem like fine names for the
> readonly
> > subtype.
>
> In Roc's explanation, the readonly one (you can't change the values,
> but something else might be able to) is the common superclass.  As he
> argued, I'm pretty sure this satisfies LSP - an immutable class is a
> valid subclass of a readonly one (you lose nothing, and gain the
> ability to depend on the values staying constant), and a mutable class
> is also a valid subclass of a readonly one (again, you lose nothing,
> but you gain the abiilty to alter the values yourself).
>
> ~TJ
>



-- 
    Cheers,
    --MarkM
Received on Thursday, 3 October 2013 20:55:57 UTC

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