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

Re: Figuring out easier readonly interfaces

From: Mark S. Miller <erights@google.com>
Date: Thu, 17 Oct 2013 13:52:52 -0700
Message-ID: <CABHxS9hza9uwuvba1D8hZgB6yqA=67d+=9nREm7woNPdGX0=Cg@mail.gmail.com>
To: Brandon Benvie <bbenvie@mozilla.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
+1 to DOMRectReadable


On Thu, Oct 17, 2013 at 1:49 PM, Brandon Benvie <bbenvie@mozilla.com> wrote:

> On 10/17/2013 1:45 PM, Domenic Denicola 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?
>>
>>
>>   Great example, I didn't understand the problem until this example. I'm
> also not a fan of `DOMRectRead` because that doesn't say what the thing is,
> but `DOMRectReadable` does, and I think it avoids the problem.
>
>


-- 
    Cheers,
    --MarkM
Received on Thursday, 17 October 2013 20:53:19 UTC

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