On Nov 1, 2013, at 7:13 PM, Allen Wirfs-Brock wrote:

> 
> On Nov 1, 2013, at 6:05 PM, David Bruant wrote:
> 
>> Le 02/11/2013 01:08, Brandon Benvie a écrit :
>>> On 11/1/2013 4:59 PM, Brandon Benvie wrote:
>>>> On 11/1/2013 4:31 PM, Brandon Benvie wrote:
>>>>> In the spec for Object.prototype.toString:
>>>>> 
>>>>> 'If tag is any of "Arguments", "Array", "Boolean", "Date", "Error", "Function", "Number", "RegExp", or "String" and SameValue(tag, builtinTag) is false, then let tag be the string value "~" concatenated with the current value of tag.'
>>>> 
>>>> An interesting consequence of this is that a Proxy for any of these will default to being "~" + target class. So `Object.prototype.toString.call(new Proxy([], {}))` is "[object ~Array]". But it seems the shipped has already sailed on Proxies being conspicuously not interchangeable with their targets in many cases...
>>> 
>>> Actually that's incorrect. Proxies explicitly will return "Proxy" for their tag. Same problem though.
>> In what other ways the ship has sailed?
>> At least regular objects and arrays can be faithfully interchanged I think, no? Things get complicated with Date/WeakMap/etc because of private state, but I remain hopeful a solution can be found in the ES7 timeframe (or whatever the next iteration is called).
> 
> Note, proxies do not transparently operate on target objects that have private internal state or any sort of internal dependencies upon object identify.  You can define a handler that over-rides most of the traps and make it work,  but for most built-ins doing something like:
>  Proxy (new Date, {} )  
> will give you an object that throws when methods of the target object are invoked upon it.

I just realized that the current specification of O.p.toString is a example of a method that has a identity dependency and hence won't work with default Proxy forwarding. As currently specified,
   Proxy({}, {}).toString()
would yield "[object Proxy]" rather than "[object Object]" as you (and I) might have expected.  The reason is that the default handler will lookup "toString" using the target object's [[Prototype]] chain and find the implementation in Object.prototype.  But when it invokes that method the default handler will pass the Proxy object rather than the target object of the this value.  Hence: [[object Proxy]].

This seems too wrong to me, but I'm not yet clear on an appropriate fix within O.p.toString.

>> 
>> I'm not sure about proxy returning "Proxy" as tag name. Is that a good idea? Brand feels like something that could safely transparently cross proxies.
> 
> There is a note on in the ES6 draft on that Proxy case of O.P.toStirng that says: "This could be used an isProxy test.  Do we really want that?"  Nobody has answered that question yet?  What do you mean by "band" transmitted accross proxies.  ES6 has no general concept of brand.
> 
Note, that the Proxy proposal originally came with a Proxy.isProxy function and after various discussions (for example, https://mail.mozilla.org/pipermail/es-discuss/2011-July/015935.html ) it was removed.  An brand check approach that that identifies Proxies (including the current spec. for O.p.toString) is a backdoor way of implementing Proxy.isProxy. If the reasons for removing Proxy.isProxy are valid then we should be providing such a backdoor.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131102/1b894826/attachment.html>

On Nov 1, 2013, at 7:13 PM, Allen Wirfs-Brock wrote:
> Note, proxies do not transparently operate on target objects that have private internal state or any sort of internal dependencies upon object identify.  You can define a handler that over-rides most of the traps and make it work,  but for most built-ins doing something like:
> ```js
> Proxy (new Date, {})
> ```
> will give you an object that throws when methods of the target object are invoked upon it.

I just realized that the current specification of O.p.toString is a example of a method that has a identity dependency and hence won't work with default Proxy forwarding. As currently specified,

```js
Proxy({}, {}).toString()
```

would yield "[object Proxy]" rather than "[object Object]" as you (and I) might have expected.  The reason is that the default handler will lookup "toString" using the target object's [[Prototype]] chain and find the implementation in Object.prototype.  But when it invokes that method the default handler will pass the Proxy object rather than the target object of the this value.  Hence: [[object Proxy]].

This seems too wrong to me, but I'm not yet clear on an appropriate fix within O.p.toString.

> There is a note on in the ES6 draft on that Proxy case of O.P.toStirng that says: "This could be used an isProxy test.  Do we really want that?"  Nobody has answered that question yet?  What do you mean by "band" transmitted accross proxies.  ES6 has no general concept of brand.

Note, that the Proxy proposal originally came with a Proxy.isProxy function and after various discussions (for example, https://mail.mozilla.org/pipermail/es-discuss/2011-July/015935.html ) it was removed.  An brand check approach that that identifies Proxies (including the current spec. for O.p.toString) is a backdoor way of implementing Proxy.isProxy. If the reasons for removing Proxy.isProxy are valid then we should be providing such a backdoor.