Catch-all proposal based on proxies
Mark S. Miller
erights at google.com
Thu Dec 10 16:42:28 PST 2009
On Wed, Dec 9, 2009 at 11:26 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
> On the climbing the meta, I'd like to understand how this might
> interact with other proposals.
> get - already can execute arbitrary code due to getters
> set - already can execute arbitrary code due to setters
> in - cannot for non host objects
> delete - cannot for non host objects
> enumerate - cannot for non host objects
By the currently proposed taxonomy at <
all the above are base-level operations. The list at <
explains that all the above can cause user code to execute whereas the last
three, as you point out, currently cannot.
> hasOwnProperty - cannot for non host objects
> Incidentally, is Object.prototype.hasOwnProperty(myProxy)
> O(myProxyHandler.keys().length) for proxies? This seems bad since a
> for (in) loop that filters out non-own properties would be O(n**2) on
> top of the loop body.
By the current taxonomy, Object.prototype.hasOwnProperty(myProxy) is
meta-level and always returns false on a trapping proxy, revealing that it
does not actually have any own properties.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss