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

Re: Figuring out easier readonly interfaces

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 2 Oct 2013 18:07:09 -0700
Message-ID: <CAAWBYDD-L7v+wc+1bqF2=q=fX+A7OfGAZRjWkD0ZAP2HdBUjHg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
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

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