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

Re: How to specify an object that can be mutable or immutable

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 26 Sep 2013 10:51:25 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Simon Pieters <simonp@opera.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <886AC517-148F-4D7F-B864-F2FC561D28CE@adobe.com>

On Sep 26, 2013, at 7:45 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Sep 25, 2013 at 2:21 AM, Simon Pieters <simonp@opera.com> wrote:
>> Hi
>> CSSOM View has a DOMRect interface [1], representing a rectangle. As part of
>> adding new features, it was proposed to make the attributes of DOMRect
>> mutable (for convenience, instead of having to create a new object), but in
>> some situations they should be immutable. The question is how to best
>> specify this.
>> Traditionally, I think DOM specs have just required to either throw or no-op
>> in the immutable state, regardless of JS strict mode. CSSOM's
>> CSSStyleDeclaration#cssText attribute [2] is an example that always throws.
>> Boris Zbarsky suggested it might be better to have two separate interfaces,
>> with the mutable interface has settable attributes and the immutable
>> interface has readonly attributes. [3]
> Could we address this without having to define identical interfaces?
> We don't have to define a special interface for arrays of Foos, we
> just write sequence<Foo>.  Could we just have readonly<Foo> to mean
> "Foo, but all of its attributes no-op on set"?
> This could be sufficiently magical to also work on [MapClass] and
> [SetClass] interfaces, to make their set/delete/add/clear/etc. methods
> automatically no-op.
> Defining two interfaces is just so, so clumsy, and a maintenance
> hazard, as it means that you have to do both "partial Foo {...}" and
> "partial ReadonlyFoo {...}" when extending the interface.

Yes, I fully share your concern.


> ~TJ
Received on Thursday, 26 September 2013 17:52:09 UTC

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