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

Re: Figuring out easier readonly interfaces

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Wed, 2 Oct 2013 15:41:42 -0700
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-Id: <C1959CFE-5749-4C0C-81E8-59069EBF7E51@wirfs-brock.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Oct 2, 2013, at 2:10 PM, Tab Atkins Jr. wrote:

> There are several places in the platform where a given interface can
> be mutable or readonly, depending on how it's used, and several more
> coming up.  Right now, this is extremely painful to do - you have to
> design two separate interfaces and keep them in lockstop (including
> when other specs add to your interfaces), or else do other non-obvious
> tricks.
> 
> In the recent thread about DOMPoint and DOMPointLiteral, I suggested
> the idea of letting WebIDL just take care of this automatically, by
> adding a syntax like "readonly<Foo>" to indicate that a
> normally-mutable Foo interface is instead readonly in this instance.
> I was asked to explain what this would mean in terms of JS, to avoid a
> boondoggle of difficult-to-implement things that were attractive and
> easy to specify in WebIDL.
> 
>> From what I can tell, the easiest way to do this is to use a Proxy
> around the mutable instance, which intercepts the "set" and
> "deleteProperty" traps (and maybe "defineProperty"?) and cancels them,
> and forwards the rest of the traps.
> 
> Further, for [MapClass] and [SetClass] interfaces, the proxy
> intercepts any Gets of the "set", "delete", or "clear" properties and
> instead returns a method that either no-ops or throws.  (I think that
> ArrayClass things are already covered by preventing property
> modification, since arrays store all their data in properties.)
> 
> Whether readonly things should throw or no-op when you attempt to
> alter them is independent, and can be decided either way under this
> proposal.  (Not saying that this should be *controllable* in WebIDL,
> just that we can make either choice when defining this.)
> 
> Thoughts?

Note that use of Proxy objects are likely to disable some or all optimization in many engines.

Also, note that it is difficult to correctly create a mostly transparent proxy for any object that has private internal state or any other sort of object identify dependency. You essentially have to use a full membrane style proxy for such objects.

Allen
Received on Wednesday, 2 October 2013 22:42:17 UTC

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