Figuring out easier readonly interfaces

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