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
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
I fully agree that isProxy sounds like a bad idea. It just breaks the
proxy abstraction.
/Andreas
On 13 July 2011 10:26, Andreas Gal g...@mozilla.com wrote:
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
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.
David
Le 13/07/2011 10:26, Andreas Gal a écrit :
I really don't think IsProxy is a good idea. It can lead to
isProxy is definitely a meta-layer operation and you don't want it polluting
the application layer. However, when you doing proxy level meta programming I
can imagine various situations where you might need to determine whether or not
an object is a proxy. I think it should exist, but should
Putting private properties on a proxy or storing it in a weak map are simple
protocols you can use to keep track of proxies that you know about. You can
hide or expose this information then without however many or few clients you
like. If you want to give people access to knowledge about your
If you created the proxy, you can use a weak map to keep track of the fact that
its a proxy (and even more precisely, its one of the proxies you created with
your handler).
Andreas
On Jul 13, 2011, at 8:31 AM, Allen Wirfs-Brock wrote:
isProxy is definitely a meta-layer operation and you
On Jul 13, 2011, at 1:23 AM, Tom Van Cutsem wrote:
Perhaps Proxy.isProxy was used merely as an example,
That's right, it was one of several in seeking for naming conventions, and
deeper distinctions among type-testing predicates. Not to worry -- I agree we
should remove it.
/be
but wasn't
On Jul 13, 2011, at 8:44 AM, David Herman wrote:
Putting private properties on a proxy or storing it in a weak map are simple
protocols you can use to keep track of proxies that you know about. You can
hide or expose this information then without however many or few clients you
like. If
There are various ways that implementation details can get exposed. For
example, by toString'ing a method property. I don't see why isProxy is any
more of an abstraction leak than toString. It is actually less, if we
clearly position it as one of the meta-programming functions that are
10 matches
Mail list logo
