Allen Wirfs-Brock (2013-11-02T02:13:36.000Z)
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'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.

We could handle that case by internally doing O.p.toString.cal(this.[[target]]) for the proxy case.  Or we could just turn it into this.toString().  But neither of those seem particularly correct, in general.

Or we could simply not special case Proxy exotic objects and then Proxies would be handled like any other object, the value of the objects @@toStringTag property would be accessed and used to compose the toString result.

Allen
domenic at domenicdenicola.com (2013-11-12T18:55:37.728Z)
On Nov 1, 2013, at 6:05 PM, David Bruant wrote:
> 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:

```js
Proxy (new Date, {})
```

will give you an object that throws when methods of the target object are invoked upon it.

> 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.

We could handle that case by internally doing O.p.toString.cal(this.[[target]]) for the proxy case.  Or we could just turn it into this.toString().  But neither of those seem particularly correct, in general.

Or we could simply not special case Proxy exotic objects and then Proxies would be handled like any other object, the value of the objects @@toStringTag property would be accessed and used to compose the toString result.