Allen and I had a conversation that clarified things. Essentially, the plan is to only have [[PreventExtensions]]/[[IsExtensible]] internal MOP methods, and to only have the corresponding preventExtensions/isExtensible traps for proxies.
Proxies won't have isSealed, isFrozen, seal and frozen traps and there will be no corresponding Reflect.{isSealed,isFrozen,seal,frozen} methods. Calling Object.freeze(proxy) instead triggers the proxy's getOwnPropertyNames trap and then updates each own property of the proxy via defineProperty. Similar story for Object.isFrozen(proxy). Pro: - We get rid of 4 MOP methods ([[Freeze]],[[Seal]],[[IsFrozen]],[[IsSealed]]). This simplifies both the internal MOP and the Proxy API. - Freezing and sealing always behave consistently, even in the face of proxies. There's no chance for a proxy to implement multiple traps inconsistently. Con: - Object.freeze(proxy) and Object.isFrozen(proxy) must observably iterate over all own properties of the proxy (same for seal/isSealed). Cheers, Tom 2013/3/18 Tom Van Cutsem <tomvc...@gmail.com> > Ok, somehow I had completely missed "9.3.10 TestIntegrityLevel (O, level)" > which does exactly the derived computation for sealed and frozen objects. > > I think André is right though about the bug in 8.3.3 step 2.a. > > Cheers, > Tom > > > 2013/3/17 Allen Wirfs-Brock <al...@wirfs-brock.com> > >> Tom recently suggested that that we really don't need MOP-level or trap >> operations from freezing, sealing and testing those states. Also, there >> seems to be minimal support for having explicit freeze/sealed integrity >> states or for adding integrity integrity states. So I'm probably going to >> go make to an style design. We'll only have [[IsExtensible]] and >> [[PreventExtensions]] MOP/trap/Reflect operations. >> Object.freeze/seal/isFrozen/isSealed will be derived operations. >> >> Allen >> >> >> >> On Mar 17, 2013, at 10:16 AM, Tom Van Cutsem wrote: >> >> Hi, >> >> Allen's latest draft (Rev. 14) contains the change where >> [[Freeze]],[[Seal]] and [[PreventExtensions]] have been consolidated into >> [[HasIntegrity]]/[[SetIntegrity]]. While no changes were made to the Proxy >> API (i.e. no has/getIntegrity traps yet), the definition of >> Object.{freeze,seal,preventExtensions} did change, and this is sufficient >> to expose an incompatibility with ES5, namely: >> >> Object.isFrozen(Object.preventExtensions({})) // true in ES5, false in >> ES6 Rev14 draft >> >> I still feel like the consolidation isn't worth this incompatibility. >> >> Allen, could you clarify what your intent is? Is it your intent that >> this incompatibility will be fixed with further spec changes? >> >> Cheers, >> Tom >> >> 2013/2/21 Brendan Eich <bren...@mozilla.com> >> >>> Tom Van Cutsem wrote: >>> >>>> That said, I don't think this is enough evidence either for or against >>>> the breaking change. >>>> >>> >>> I have a hard time believing we can break ES5. It has been shipping for >>> years (plural, at least in one case) in major browsers that evergreen their >>> user bases. >>> >>> /be >>> >> >> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss