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.

>>  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.

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