Re: Figuring out easier readonly interfaces

On Thu, Oct 3, 2013 at 11:02 AM, Allen Wirfs-Brock <allen@wirfs-brock.com>wrote:

>
> On Oct 3, 2013, at 6:17 AM, Mark S. Miller wrote:
>
> 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? :-)
>>
>
> Well a; subclass (subtype) in this concept is a specialization of a more
> general concept. It adds an additional capability that isn't present in the
> more general abstraction. In this case the specializations we are adding
> are the ability to change the coordinates of a rectangle or the assurance
> that the coordinates will not observably change.
>
> From that perspective, I would name the most general concept:
>
> DOMRect  -- it encompass all rectangle used by the DOM
> DOMVarRec  -- it specializes DOMRect by adding the ability to vary its
> coordinates.
> DOMImmutableRec  It never changes
>

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 any case, using the generic short name for the common supertype is what
I did in E. When I first proposed Map, Set, and WeakMap for JS, I purposely
chose to violate the E convention of which one gets the simple name. I
agree with Tab. I think for JS, E's convention would be a mistake. The
conventional case in JS by far is the normal mutable one. The other four
concepts that need names are oddball concepts normally absent from
historically-conventional JS code. Whatever we do here for DOMRect, we
should consider doing -- post ES6 -- for Map, Set, and WeakMap as well (and
perhaps also TypedArray?), where we've already given the simple name to the
normal mutable abstraction.

My case here would of course be stronger if I had a good suggestion for
naming the common supertype. but I don't. Suggestions appreciated.


-- 
    Cheers,
    --MarkM