The best defense is Object.freeze(Object.prototype);
No application worth considering needs to arbitrarily modify
Object.prototype at an arbitrary point in time (or someone should bring
a use case for discussion). It usually shouldn't and even if it does, it
should do it at startup and freeze it afterwards.
Le 13/11/2014 12:25, Andrea Giammarchi a écrit :
well, Proxy can be a diabolic beast
```js
Object.setPrototypeOf(
Object.prototype,
new Proxy(Object.prototype, evilPlan)
)
```
having no way to understand if an object is a Proxy looks like a
footgun to me in the long term, for libraries, and "code alchemists"
You're giving guns to people and try to evaluate how to defend from
them. Consider not letting guns around the rooms ;-)
David
You indeed wrote that different Array methods need to know if there's
a Proxy in there ... if dev cannot know the same via code they are
unable again to subclass properly or replicate native behaviors behind
magic internal checks.
If there is a way and I'm missing it, then it's OK
Regards
On Thu, Nov 13, 2014 at 7:15 AM, Tom Van Cutsem <tomvc...@gmail.com
<mailto:tomvc...@gmail.com>> wrote:
2014-11-12 23:49 GMT+01:00 Andrea Giammarchi
<andrea.giammar...@gmail.com <mailto:andrea.giammar...@gmail.com>>:
If Array.isArray should fail for non "pure" Arrays, can we
have a Proxy.isProxy that never fails with proxies ?
We ruled out `Proxy.isProxy` very early on in the design. It's
antithetical to the desire of keeping proxies transparent. In
general, we want to discourage type checks like you just wrote.
If you're getting handed an object you don't trust and need very
strong guarantees on its behavior, you'll need to make a copy.
This is true regardless of proxies. In your example, even if the
array is genuine, there may be some pointer alias to the array
that can change the array at a later time.
Regards,
Tom
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
