[[Extensible]]and Proxies (Was: Proxy.isProxy )

Brendan Eich brendan at mozilla.com
Sun Jul 17 18:01:39 PDT 2011


On Jul 17, 2011, at 3:18 PM, David Bruant wrote:

> Le 15/07/2011 00:16, Brendan Eich a écrit :
>> 
>> On Jul 14, 2011, at 3:00 PM, Allen Wirfs-Brock wrote:
>> 
>>>> Host objects are part of the platform. A platform provider is free to violate any part of the spec they like, and there's nothing we can do about it other than to add tests to std test suites to make the violations obvious to the community.
>>> 
>>> We could provide a defined interface mechanism that validates constraints or limits behavior in a way that guarantees the desired invariants. That's what Proxies appear to be trying to do, why not do it for host objects.  If you can depend upon host objects actually supporting your invariants why does not matter whether or not Proxy objects also do so.
>> 
>> For the record, Mozilla wants its "host objects" to be only as powerful as Proxies. Current web compatibility constraints don't allow this but we want to evolve the standards, de facto (over time) and de jure, toward that goal.
> Do you have examples?

David Flanagan is in the thick of dom.js work (https://github.com/andreasgal/dom.js), so he should comment. IIRC at least configuring [[Class]] name as exposed by Object.prototype.toString, and of course fixed properties on pre-fixed Proxies, have come up in the course of self-hosting the DOM.


>> Some Proxy extensions may be needed, too, so it's not all up to web compatibility to take the hit.
> Do you have such Proxy extensions in mind already?

See my previous reply, about fixed properties, the fix trap, controlling the [[Class]] of the object the proxy "becomes" upon fixing, and preserving the (preventExtensions, seal, freeze) distinction when fixing.

/be


More information about the es-discuss mailing list