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

Re: Figuring out easier readonly interfaces

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 3 Oct 2013 09:28:54 -0400
Message-ID: <CAOp6jLb56xfXmJSJTvBC_cvaUsNYRrA5BxpAzzU-8GpwBB9-xQ@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
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.

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  *
*
Received on Thursday, 3 October 2013 13:29:21 UTC

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