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

Figuring out easier readonly interfaces

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 2 Oct 2013 14:10:36 -0700
Message-ID: <CAAWBYDAOGAH=rkx5aZ5YO2nVVi_f+VYR2+_P5zh3=BzOM7dWrg@mail.gmail.com>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
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?

~TJ
Received on Wednesday, 2 October 2013 21:11:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 October 2013 21:11:28 UTC