Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 bren...@mozilla.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 bren...@mozilla.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 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 bren...@mozilla.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 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 bren...@mozilla.com mailto:bren...@mozilla.com 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@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 exist in a namespace that is clearly part of the meta-layer. Arguably Proxy, itself, is such a namespace. But if there is fear that it is too close to the app layer then we might hand it from Proxy.Handler or something else that is clearly on the meta side. Or have a Proxy support modules. Allen On Jul 13, 2011, at 2:07 AM, David Bruant wrote: 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 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 bren...@mozilla.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 proxy, you can share the private name object or weak map so that they can look it up, or even provide a similar predicate to isProxy. By contrast, if you want to virtualize an object with a proxy and we provide isProxy, we've made it almost impossible to protect the abstraction. It becomes a universal on-off switch that you can turn off by hiding the isProxy predicate (via module loaders or deleting/mutating the function). And to be even more concrete, if we want to use proxies for platform-level features, e.g. the DOM, then isProxy is something we *can't* turn off without violating the ECMAScript spec, so we're then *forced* to expose the implementation detail to anyone on the web who wants to look at it. Dave On Jul 13, 2011, at 8:31 AM, Allen Wirfs-Brock wrote: 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 exist in a namespace that is clearly part of the meta-layer. Arguably Proxy, itself, is such a namespace. But if there is fear that it is too close to the app layer then we might hand it from Proxy.Handler or something else that is clearly on the meta side. Or have a Proxy support modules. Allen On Jul 13, 2011, at 2:07 AM, David Bruant wrote: 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 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 bren...@mozilla.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 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 exist in a namespace that is clearly part of the meta-layer. Arguably Proxy, itself, is such a namespace. But if there is fear that it is too close to the app layer then we might hand it from Proxy.Handler or something else that is clearly on the meta side. Or have a Proxy support modules. Allen On Jul 13, 2011, at 2:07 AM, David Bruant wrote: 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 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 bren...@mozilla.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 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 bren...@mozilla.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 you want to give people access to knowledge about your proxy, you can share the private name object or weak map so that they can look it up, or even provide a similar predicate to isProxy. I buy that a non-reflectable private name can be used to brand proxies. Coming from the perspective of a GC implementer, I'm suspicious of all arguments that are backstopped by requiring the use of weak maps, as their existence and size impose GC overhead. Yes, there are some things that really require them, but without knowing the volume and volatility of the objects involved it is hard to say whether or not weak maps is going to be an acceptable solution for any particular problem. By contrast, if you want to virtualize an object with a proxy and we provide isProxy, we've made it almost impossible to protect the abstraction. It becomes a universal on-off switch that you can turn off by hiding the isProxy predicate (via module loaders or deleting/mutating the function). We want to stratify reflective meta-programming. Violating the abstraction barrier of a proxy based abstraction is fine (and necessary), as long as you are operating in the meta strata. isProxy would clearly be a virtualization hazard if it existed on Proxy instances. But as one of the stratified proxy-related reflective operations it isn't. And to be even more concrete, if we want to use proxies for platform-level features, e.g. the DOM, then isProxy is something we *can't* turn off without violating the ECMAScript spec, so we're then *forced* to expose the implementation detail to anyone on the web who wants to look at it. So far, there is nothing in the ECMAScript spec. that says anything about whether or not Proxy's may be used to implement built-ins, host objects, or anything else and by implication what isProxy (if it exists) might report for such objects. I'd just as soon leave it that way. 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 available via the Proxy module. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy.isProxy (Was: using Private name objects for declarative property definition.)
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 available via the Proxy module. I think this is a very weak argument. Just because we already have one leaky abstraction (toString) doesn't mean we should add additional ones. I prefer moving into the opposite direction: fix toString. Andreas Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
