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
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
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
The incompatibility you've noticed is just a spec bug in
[[HasIntegrity]]. In step 2a of 8.3.3, the value of [[Extensible]] needs
to be inverted. With that change applied, the code snippet will return
`true`.
- André
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
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
On Feb 20, 2013, at 9:24 AM, Tom Van Cutsem wrote:
2013/2/18 Andreas Rossberg rossb...@google.com
On 16 February 2013 20:36, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It's to simplify the MOP and that simplification is directly reflected as
a simplification to the Proxy hander
Allen Wirfs-Brock wrote:
I think I previously asked if anybody is aware of situations where
Object.isFrozen tests are done but Object.freeze is not used to set
objects to the frozen state. So far, no answers. Anybody?
Speaking just from my own experience as a user of ES5, I have not found
On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall nathan.w...@live.com wrote:
`Object.isFrozen` and `Object.isSealed` don't really seem that helpful to
me for the very reasons you've discussed: They don't represent any real
object state, so they don't accurately tell me what can be done with an
Le 20/02/2013 21:08, Kevin Reid a écrit :
On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall nathan.w...@live.com
mailto:nathan.w...@live.com wrote:
`Object.isFrozen` and `Object.isSealed` don't really seem that
helpful to me for the very reasons you've discussed: They don't
represent
On Wed, Feb 20, 2013 at 12:15 PM, David Bruant bruan...@gmail.com wrote:
And in an ES6 world, you'll probably use an actual WeakMap anyway?
Using an actual WeakMap does not change matters: the intent is that after
Object.freeze(o), you can't add new trademarks to o. Since the trademark
info is
(I do not yet have an overall opinion about get/setIntegrity. Here, I'm
just answering and clarifying, not advocating.)
On Wed, Feb 20, 2013 at 10:57 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
[...]
Also, I'm concerned that we have been overloading the meaning of the
[[Extensible]]
Allen Wirfs-Brock wrote:
Actually, no. Reducing API complexity (in this case, the Proxy
handler API) at the expense of a little bit of added spec. complexity
seems like a very reasonable trade-off. Plus, we are talking about
spec. complexity, not necessarily implementation complexity.
2013/2/20 Allen Wirfs-Brock al...@wirfs-brock.com
Finally, I still think we should further consider the feasibly of a
breaking change where
Object.preventExtensions(obj); for ( let k of
Object.getOwnPropertyKeys(obj))
Object.defineProperty(obj,k,{configurable:false});
is no longer
14 matches
Mail list logo
