Proxy.isProxy (Was: using Private name objects for declarative property definition.)

David Bruant david.bruant at
Wed Jul 13 02:07:52 PDT 2011

And in general, the main use case for proxies is to emulate host 
objects. If there is a language construct that helps separating the two 
cases, we're going against this use case.


Le 13/07/2011 10:26, Andreas Gal a écrit :
> I really don't think IsProxy is a good idea. It can lead to subtle 
> bugs depending on whether an object is a DOM node, or a wrapper around 
> a DOM node (or whether the embedding uses a proxy to implement DOM 
> nodes or not). In Firefox we plan on making some DOM nodes proxies for 
> example, but not others. I really don't think there is value in 
> exposing this to programmers.
> Andreas
> On Jul 13, 2011, at 1:23 AM, Tom Van Cutsem wrote:
>> Perhaps Proxy.isProxy was used merely as an example, but wasn't the 
>> consensus that Proxy.isProxy is not needed? Dave pointed out that it 
>> breaks transparent virtualization. Also, there is Object.isExtensible 
>> which always returns |true| for (trapping) proxies. That means we 
>> already have "half" of Proxy.isProxy without exposing proxies: if 
>> !Object.isExtensible(obj), obj is guaranteed not to be a proxy.
>> Cheers,
>> Tom
>> 2011/7/9 Brendan Eich <brendan at <mailto:brendan at>>
>>     Also the Proxy.isTrapping, which in recent threads has been
>>     proposed to be renamed to Proxy.isProxy or Object.isProxy.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at <mailto:es-discuss at>
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list