Re: Figuring out easier readonly interfaces

On 10/2/13 5:42 PM, Tab Atkins Jr. wrote:
> It's doing that outside of ES, then.

Yes, of course.  That's what the DOM implementation tends to do: work 
non-ES-accessible state!

> Within ES, there shouldn't be
> any way to pierce the Proxy boundary unless you do it on purpose.
> It's not very fair to ask me to explain how to implement something in
> ES, and then point out that since it's not actually implemented in ES
> none of my ideas can possible work. :/

What's desired here is explaining how your proposal maps to what will 
actually happen in an implementation.  That is, what ES MOP operations 
will happen on which objects, and for those MOP operations that then end 
up operating on the not-script-accessible internal DOM state (e.g. the 
[[Call]] of various methods that WebIDL defines, including property 
getters and setters) what those MOP operations will do.

>> Say you had a readonly<Node> and you got the "id" setter off
>> Element.prototype and called it.  What would happen, and why?
> What *should* happen is that it tries to set "id" on the Node
> instance

Uh... Back up.  What does that actually _mean_?  I think your problem is 
you're skipping steps and handwaving instead of actually carefully 
stepping through what happens here.

What the "id" setter is defined to do at and then at and then at is to take 
the "this" object, make sure it "implements the Element interface", then 
take that Element's "attribute list" (which is some other totally 
unrelated object, presumably looked up in a WeakMap if you're going to 
self-host) and mutate it.

Similarly, the "id" getter is defined to do all of those, except at the 
end get some information out of the "attribute list" instead of mutating it.

That's the state of things right now.

What will the state of things be in your proposal?  Will using .apply() 
on the getter off Element.prototype with a thisArg that's a 
readonly<Element> work?  If so, how?


Received on Wednesday, 2 October 2013 21:50:32 UTC