The element object is a special object created by browser internals. It has various kinds of state associated with it, e.g. via internal slots. The proxy object doesn’t have these slots. They’re not like properties; there is no object internal method for e.g. ‘getSlotValue’. They’re more like values in a WeakMap which is keyed by the object’s identity (the same model as private fields). There are various reasons why they could not be made to ‘pass through’ (I could try to explain this further, but I’m not sure I’m the right person to explain it effectively, as I barely understand certain issues there). But in any case, from the browser’s perspective, a proxy exotic object is an entirely different object. It’s not a platform object or an element.
In userland classes, we can associate private state with proxies freely with various mechanisms. But to do this, it has to be done after the fact — you need to actually have access to the new overridden object somewhere. The construction algorithm doesn’t operate in the right ‘direction’ to permit this: each derived constructor has an opportunity to perform a return override, but only more derived constructors will receive the new object as their `this`; the previous constructors and the base constructor have already completed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/857#issuecomment-560013858