2009/12/10 Mark S. Miller <[email protected]>: > On Wed, Dec 9, 2009 at 11:26 PM, Mike Samuel <[email protected]> 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 > <http://wiki.ecmascript.org/doku.php?id=strawman:proxies#interaction_of_external_methods_and_proxies>, > all the above are base-level operations. The list at > <http://wiki.ecmascript.org/doku.php?id=strawman:proxies#climbing_the_meta_ladder> > 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 "in/enumerate". >> 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 (Object.hasOwnProperty.call(o, k)) ... ? That seems to make it less useful. > -- > Cheers, > --MarkM > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
