Let's avoid all-or-nothing judgments about Proxies, they are definitely
a practical, standardizable thing -- so a work in progress, subject to
further improvement.
Proxies are meant to be transparent in general. Exceptions include
built-ins with magic internal properties. We haven't added private data
(ideally the basis for self-hosting such built-ins) yet, and we'd need
extensions to Proxies should we do so. Etc.
That someone might make a proxy-for-array that violates an Array
invariant is just part of the bargain: a bug or feature, depending on
situation. We still may want Array.isArray on a proxy-for-array to
return true, all things considered.
/be
Allen Wirfs-Brock wrote:
On Nov 12, 2014, at 11:58 AM, Jeremy Martin wrote:
My opinion is that array testing is fundamental to core JS and is
worth the exception.
Knowing that Array.isArray() tests fail for proxies, I'd be afraid to
ever create a Proxy for an array that I don't control the complete
lifecycle of. That seems to critically inhibit the usefulness of
Proxies, especially when transparency seems to have been an intended
characteristic of them going all the way back to the strawman days.
Proxies are not transparent forwarders! In particular their default
handling of the `this` value on method invokes will break any built-in
method that needs to access "internal slots" of an object.
```js
var p = new Proxy(new Array, {});
```
will give you an object that will fail on serval of the
Array.prototype methods.
It is even worse for other built-ins such as Map or the typed array
constructors.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
