Re: Figuring out easier readonly interfaces

On Thu, Oct 3, 2013 at 5:50 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> I agree with Mark. There is no way to automatically derive the read-only
> version of an interface. So at least we'd need per-member annotations that
> describe how to a readonly<Foo> is related to a Foo.
>
> The approach I'm pushing for DOMRect in www-style seems much simpler to
> me: have (conceptually) three separate interfaces:
> -- DOMRectReadOnly: an interface exposing read-only accessors to the
> current state of a DOMRect. Nothing is said about whether the object is
> mutable or not.
> -- DOMRect: a subinterface of DOMRectReadOnly, exposing mutating APIs.
> -- DOMRectImmutable: a subinterface of DOMRectReadOnly, which guarantees
> that the state never changes.
> This approach satisfies the LSP. There's minimal duplication of
> methods/attributes. It works well in WebIDL since WebIDL already allows
> attributes to be readonly in DOMRectReadOnly and writable in DOMRect. (In
> this specific example we don't need DOMRectImmutable right now so we won't
> define it.) What's not to like? :-)
>


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.




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


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

Ok, I'll bite. What does your cryptic signature mean?



-- 
    Cheers,
    --MarkM