Re: Figuring out easier readonly interfaces

It's not just property getting and setting. Your Map and Set examples are
special cases of the more general issue. In order to do a readonly facet of
an abstraction, you have to know what public methods of the underlying
abstraction are pure query methods vs potentially mutating methods. This
knowledge is not represented in any generic form, and so this faceting
can't be built as a generic proxying abstraction. You have to build
type-specific facets. You could express those facets with proxies, but
there's no reason to.


On Wed, Oct 2, 2013 at 2:10 PM, Tab Atkins Jr. <jackalmage@gmail.com> 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?
>
> ~TJ
>
>


-- 
    Cheers,
    --MarkM