Catch-all proposal based on proxies

Mike Samuel mikesamuel at
Thu Dec 10 17:09:12 PST 2009

2009/12/10 Mark S. Miller <erights at>:
> On Wed, Dec 9, 2009 at 11:26 PM, Mike Samuel <mikesamuel at> 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.

Yes, sorry.  I didn't mean to simply reiterate your writeup.  I was
trying to figure out which ops might end up being able to invoke
arbitrary code based on other proposed features.  I can't think of any
though since iterators seem to not involve virtualizing

>> 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.

Hmm.  So a proxy of an object cannot be used as a drop-in replacement
for that object with any code that uses own property loops like
   for (var k in o) if (, k)) ...
That seems to make it less useful.

> --
>    Cheers,
>    --MarkM

More information about the es-discuss mailing list