On Jul 30, 2013, at 12:40 PM, David Bruant wrote:

> Le 30/07/2013 18:57, Allen Wirfs-Brock a écrit :
>> ...
> 
>> But it still doesn't work the way you would like for direct "call" invocation or for things like Array.isArray.  The base issue for either of these is that they don't indirect through the proxy handler and hence the handler doesn't have an opportunity to replace the proxy reference with the target reference. 
> Wouldn't replacing the proxy reference for the target reference be violating stratification?

It depends upon the use for the proxy.  There is no stratification if the Proxy is being used to implement the a virtual object.  

> Per exotic type traps would solve the issue generically, I think.

It might for ES6 and for this use case.  But it doesn't generalize to user defined classes with private state.  It also does solve the problem for identity based testing.  EG, using a WeakMap for branding or holding private state.  The Proxy object and its target object are not the same map key.

> 
> 
>> Do you have new use cases, that motivate the design of an enhanced Array.isArray?
> I cited membrane transparency a couple of times. Tom seems to agree. Others have opinions?

I was really asking about purpose of application level Array.isArray tests.  What is the application really asking when it uses that test? Is it really asking "array-like"?  What counts as "array-like"?

> 
>> 
>> It would be quite easy to extend Array.isArray(obj) so that it delegated back to obj with a @@areYouAnArray method such as we are doing with @@isRegExp in certain places.  However, if we do that you loose support for the original Array.isArray use case because any object could decide to return true from Array.isArray. 
>> ...
> If, for instance, you have an "areYouAnArray" trap that only works if the target is an Array (recursive definition with actual arrays as base case), then Array.isArray isn't spoofable by any object.
> Mark and Tom once used a expression about direct proxies. Something like "invariant forwarding" or something like that, where the target imposes restrictions on the handler. This could be extended to exotic objects by adding per exotic type only traps.

Let me reinterpret this as as request for a [[GetNomimalType]] trap.  What are the set of expected values?  What happens if the handler lies? What could somebody do with the result?  

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130730/92841530/attachment.html>

On Jul 30, 2013, at 12:40 PM, David Bruant wrote:

> Wouldn't replacing the proxy reference for the target reference be violating stratification?

It depends upon the use for the proxy.  There is no stratification if the Proxy is being used to implement the a virtual object.  

> Per exotic type traps would solve the issue generically, I think.

It might for ES6 and for this use case.  But it doesn't generalize to user defined classes with private state.  It also does solve the problem for identity based testing.  EG, using a WeakMap for branding or holding private state.  The Proxy object and its target object are not the same map key.

> I cited membrane transparency a couple of times. Tom seems to agree. Others have opinions?

I was really asking about purpose of application level Array.isArray tests.  What is the application really asking when it uses that test? Is it really asking "array-like"?  What counts as "array-like"?

> If, for instance, you have an "areYouAnArray" trap that only works if the target is an Array (recursive definition with actual arrays as base case), then Array.isArray isn't spoofable by any object.
> Mark and Tom once used a expression about direct proxies. Something like "invariant forwarding" or something like that, where the target imposes restrictions on the handler. This could be extended to exotic objects by adding per exotic type only traps.

Let me reinterpret this as as request for a [[GetNomimalType]] trap.  What are the set of expected values?  What happens if the handler lies? What could somebody do with the result?