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 06:56:45 -0700
Message-ID: <CABHxS9h3unZpGB8y9537Bu3M3=u0FcB7ky3DExskL2aD_=CA_g@mail.gmail.com>
To: robert@ocallahan.org
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Thu, Oct 3, 2013 at 6:28 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Oct 3, 2013 at 9:17 AM, Mark S. Miller <erights@google.com> wrote:
>
>> This three-way distinction is what we did in E collections, but with an
>> additional distinction.
>> <http://erights.org/elang/collect/tables.html>
>> <
>> http://erights.org/javadoc/org/erights/e/elib/tables/package-summary.html
>> >
>> For example, our Map abstraction has FlexMap, ConstMap, and ReadOnlyMap.
>> All are subtypes of Map. Neither ConstMap nor ReadOnlyMap change the
>> signature of Map, but they do represent an LSP contractual commitment not
>> made by Map:
>> * ConstMap is immutable, like your DOMRectImmutable
>> * FlexMap extends Map with mutation methods, just as your DOMRect
>> extends its supertype.
>> * ReadOnlyMap guarantees that the Map may not be mutated via an instance
>> of ReadOnlyMap. IOW, giving someone a ReadOnlyMap gives them the ability to
>> observe mutations but not the ability to cause them.
>>
>> Note that the "mutation" that ReadOnly prevents is to the mapping
>> provided by the map. In a world with Object.observe, registering an
>> observer on a ReadOnlyMap should effectively register it on the underlying
>> map. This is a mutation of the observer registry associated with the Map,
>> by it is not a means by which multiple observers might communicate with
>> each other.
>>
>
> That makes sense.
>
> I think that for WebIDL we won't normally need a specific interface for
> your "ReadOnlyMap" concept. A DOMRectReadOnly is perfectly adequate for
> objects which are mutable by the UA but not by script. (E.g.
> DOMQuad.bounds.)
>
>
>>
>>>  FWIW we give the mutable type the shortest, most obvious name since we
>>> expect the most common usage of any of these names in user code will be to
>>> construct new instances of the mutable type.
>>>
>>
>> This is the right approach for JavaScript. But then we need a general
>> naming scheme for the common supertype. Suggestions?
>>
>
> Just appending ReadOnly makes sense to me.
>

But a DOMRect is mutable by script, and so is not an LSP subtype of
DOMRectReadOnly.




>
> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w  *
> *
>



-- 
    Cheers,
    --MarkM
Received on Thursday, 3 October 2013 13:57:16 UTC

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