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

Re: Figuring out easier readonly interfaces

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 3 Oct 2013 14:06:42 -0700
Message-ID: <CAAWBYDCNBc8y3QNBwnTn6rG4+DFvNd+5TByNb6X0Ay7-=taaQA@mail.gmail.com>
To: "Mark S. Miller" <erights@google.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>
On Thu, Oct 3, 2013 at 1:55 PM, Mark S. Miller <erights@google.com> wrote:
> 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).
>
> 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".

I'm not particularly interested in making the name less readable to
make the name *itself* better match LSP.

~TJ
Received on Thursday, 3 October 2013 21:07:28 UTC

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