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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
