Hi,

Originally, direct proxies were specified such that a direct proxy would
inherit the [[Class]] of the target object it wraps. The intent was for
e.g. proxies-for-arrays to be recognized properly as arrays.

In ES6 the [[Class]] property is gone and the current draft instead uses
wording such as "if O is an exotic Array object..."

My understanding is that a proxy for an array would not pass such a test,
unless we explicitly state otherwise.

Allen, could you clarify your intent?

If proxies for arrays do not pass such tests, some built-ins behave in
unexpected ways.

Here's the list of relevant built-ins, based on searching the ES6 spec for
"is an exotic Array object":
* Object.prototype.toString
* Array.isArray
* Array.prototype.concat
* JSON.stringify
* JSON.parse
* ArrayBuffer.isView

If we don't make proxies-for-arrays work transparently, we get results such
as:

var p = new Proxy( [1,2] , {} );

Object.prototype.toString.call(p) // "[object Object]", expected "[object
Array]"
Array.isArray(p) // false, expected true
[0].concat(p) // [0,p], expected [0,1,2]
JSON.stringify(p) // "{\"0\":1,\"1\":2}", expected "[1,2]"

Note that none of these built-ins actually relies upon some structural
array invariant. Passing in a proxy that has properties such as "length",
"0", etc. works equally well.


It's worth noting that I hit upon these issues because users of my
harmony-reflect shim, which are using direct proxies today in ES5, have
reported them (see [1],[2]). This adds some evidence that users expect the
above built-ins to behave transparently w.r.t. proxies for their use
cases. My library patches some of these built-ins to recognize my own
emulated proxies, but this is just an ad hoc solution. ES6 users will
obviously not be able to do this.

Cheers,
Tom

[1] https://github.com/tvcutsem/harmony-reflect/issues/13
[2] https://github.com/tvcutsem/harmony-reflect/issues/19
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130729/2158d435/attachment.html>

Originally, direct proxies were specified such that a direct proxy would
inherit the [[Class]] of the target object it wraps. The intent was for
e.g. proxies-for-arrays to be recognized properly as arrays.

In ES6 the [[Class]] property is gone and the current draft instead uses
wording such as "if O is an exotic Array object..."

My understanding is that a proxy for an array would not pass such a test,
unless we explicitly state otherwise.

Allen, could you clarify your intent?

If proxies for arrays do not pass such tests, some built-ins behave in
unexpected ways.

Here's the list of relevant built-ins, based on searching the ES6 spec for
"is an exotic Array object":

* Object.prototype.toString
* Array.isArray
* Array.prototype.concat
* JSON.stringify
* JSON.parse
* ArrayBuffer.isView

If we don't make proxies-for-arrays work transparently, we get results such
as:

```js
var p = new Proxy( [1,2] , {} );

Object.prototype.toString.call(p) // "[object Object]", expected "[object Array]"
Array.isArray(p) // false, expected true
[0].concat(p) // [0,p], expected [0,1,2]
JSON.stringify(p) // "{\"0\":1,\"1\":2}", expected "[1,2]"
```

Note that none of these built-ins actually relies upon some structural
array invariant. Passing in a proxy that has properties such as "length",
"0", etc. works equally well.


It's worth noting that I hit upon these issues because users of my
harmony-reflect shim, which are using direct proxies today in ES5, have
reported them (see https://github.com/tvcutsem/harmony-reflect/issues/13, https://github.com/tvcutsem/harmony-reflect/issues/19). This adds some evidence that users expect the
above built-ins to behave transparently w.r.t. proxies for their use
cases. My library patches some of these built-ins to recognize my own
emulated proxies, but this is just an ad hoc solution. ES6 users will
obviously not be able to do this.