Re: Figuring out easier readonly interfaces

On Wed, Oct 2, 2013 at 6:02 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/2/13 7:02 PM, Tab Atkins Jr. wrote:
>> Okay, so that's a no go in general.
>
> So here's a question.  What set of use cases are we trying to addres?

We've got a few recent ones that are useful.

* DOMRect is sometimes readonly (such as when it's the value of a
DOMQuad's .bounds property), and sometimes mutable.
* CSSVariablesMap is readonly when the CSSStyleDeclaration it's
associated with is readonaly, and mutable otherwise.
* CSSStyleDeclaration itself is sometimes readonly (when gotten from
gCS) and sometimes not.

> Defining something where setters have to automatically no-op or throw on an
> object because it's readonly is not too bad.  The complicated thing is
> (mutator) methods.  To address that you have to mark which methods are
> mutators or something.

Right, that'd be something the defining spec would explicitly address
by checking the readonly-ness of the object.

> That then still leaves the question of what happens when you pass a
> readonly<Foo> to a function that takes Foo, I guess.

As long as it doesn't try to mutate anything, it should work.  If it
does try, the attempt should no-op or throw, and have the
corresponding effect on the method.

~TJ

Received on Thursday, 3 October 2013 01:07:56 UTC