Allen Wirfs-Brock (2013-12-07T19:41:04.000Z)
On Dec 7, 2013, at 11:26 AM, Mark S. Miller wrote:

> On Sat, Dec 7, 2013 at 10:45 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> As currently specified, [[OwnPropertyKeys]] doesn't have any particular invariants on the values it generates from the returned iterator.
> 
> Mark and I proposed to reintroduce [[GetOwnPropertyNames]] as a separate internal method, which would return an array rather than an iterator, but which would also be required to return at least the names (symbols or strings) of all non-configurable properties. The switch to an array return value is motivated partly by the reasons Jason stated, but also because actually checking the invariant requires exhausting the iterator anyway.
> 
> [[OwnPropertyKeys]] would continue to return an iterator (or iterable , as Jason suggests, which seems to make more sense), but there would be no invariants on its generated values.
> 
> [[GetOwnPropertyNames]] would be the reliable way of querying an object for its own properties, and would be used at least by Object.getOwnPropertyNames and the abstract operations used by Object.{freeze,isFrozen,seal,isSealed}, so that the result of these operations can in turn be made reliable.
> 
> Hi Tom, when we talked I think we overlooked something crucial. The requirement as stated, "return at least the names (symbols or strings) of all non-configurable properties", is not actually sufficient for freeze, isFrozen, etc. We must additionally state that, if the object has been observed to be non-extensible, then it may not afterwards claim to have any own properties not observed by [[GetOwnPropertyNames]]. Without this additional requirement, a non-extensible object can "hide" non-configurable own properties from freeze, isFrozen, etc.
> 

If the primary motivation is to ensure the integrity of freeze (and seal??) then a [[Freeze]] mop operations seems like a better solution to me. 

BTW, this seems like old territory, at one time we had a [[SetIntegrity]] mop operation that could be used to implement both Object.freeze and Object.seal.  Why did we get rid of it?

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131207/79376896/attachment.html>
domenic at domenicdenicola.com (2013-12-10T02:22:22.368Z)
On Dec 7, 2013, at 11:26 AM, Mark S. Miller wrote:

> Hi Tom, when we talked I think we overlooked something crucial. The requirement as stated, "return at least the names (symbols or strings) of all non-configurable properties", is not actually sufficient for freeze, isFrozen, etc. We must additionally state that, if the object has been observed to be non-extensible, then it may not afterwards claim to have any own properties not observed by [[GetOwnPropertyNames]]. Without this additional requirement, a non-extensible object can "hide" non-configurable own properties from freeze, isFrozen, etc.
> 

If the primary motivation is to ensure the integrity of freeze (and seal??) then a [[Freeze]] mop operations seems like a better solution to me. 

BTW, this seems like old territory, at one time we had a [[SetIntegrity]] mop operation that could be used to implement both Object.freeze and Object.seal.  Why did we get rid of it?