Re: Figuring out easier readonly interfaces

Hi Domenic, essentially yes. I would only change "only its creator can
write it" to "only those given write-access can write it". At the moment of
creation, only the creator has access to the created object, so all
authorization, both read and write, must be rooted in authorization choices
made by that creator.

In any case, your example code clearly expresses the intent to propagate
read access. The fact that it actually propagates write access is a
dangerous leak of unintended authority.

Thanks for the great example!



On Thu, Oct 17, 2013 at 1:45 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> I think some example code helps this discussion. From what I can tell,
> Mark is concerned about code like this:
>
> ```js
> if (rect instanceof DOMRectReadOnly) {
>   // ok, it's read only, so only its creator can write it
>   untrustedCode.doSomethingWithRect(rect);
>   // I can assume that rect has not change.
> }
> ```
>
> This code assumes that being an instance of DOMRectReadOnly means that
> only its creator can write it, which is what the contract implied by "read
> only" means. It assumes `untrustedCode.doSomethingWithRect` won't be able
> to modify `rect`, and thus it can assume on the next line it isn't changed.
>
> However, under the proposed inheritance hierarchy, where a mutable DOMRect
> inherits from DOMRectReadOnly, this code could have its assumptions
> violated, if `rect` was a DOMRect.
>
> This seems bad?
>
>


-- 
    Cheers,
    --MarkM