On Sat, Dec 7, 2013 at 11:41 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> 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.
>

Actually, freeze and seal are examples. As another example, the SES startup
uses Object.getOwnPropertyNames to do a thorough walk of the initial
primordials, aside from the global object, and remove anything not on its
whitelist. If it does find something not on its whitelist that it can't
delete and doesn't know to be safe for other reasons, then it declares that
this platform cannot be made SES-safe. That's why <
https://bugzilla.mozilla.org/show_bug.cgi?id=724768#c8> was such a problem
for us. What the combination of non-extensible and getOwnProperties gives
us is confidence that there's nothing there beyond what we see.



>
> 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?
>

I remember I was for a time in favor of [[SetIntegrity]], and made
arguments in support of it. However, it was additional semantic state that
was approximately redundant with the state already there, and could get out
of sync with it. If now were earlier in the ES6 cycle I would be open to
reconsidering it. But it raised so many open questions that I don't think
we should reopen it unless something is broken with the current plan. If we
do reopen [[SetIntegrity]], we should decide to slip the schedule.




>
> Allen
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131207/562dff35/attachment.html>

On Sat, Dec 7, 2013 at 11:41 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> 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.

Actually, freeze and seal are examples. As another example, the SES startup
uses Object.getOwnPropertyNames to do a thorough walk of the initial
primordials, aside from the global object, and remove anything not on its
whitelist. If it does find something not on its whitelist that it can't
delete and doesn't know to be safe for other reasons, then it declares that
this platform cannot be made SES-safe. That's why https://bugzilla.mozilla.org/show_bug.cgi?id=724768#c8 was such a problem for us. What the combination of non-extensible and getOwnProperties gives
us is confidence that there's nothing there beyond what we see.



> 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?

I remember I was for a time in favor of [[SetIntegrity]], and made
arguments in support of it. However, it was additional semantic state that
was approximately redundant with the state already there, and could get out
of sync with it. If now were earlier in the ES6 cycle I would be open to
reconsidering it. But it raised so many open questions that I don't think
we should reopen it unless something is broken with the current plan. If we
do reopen [[SetIntegrity]], we should decide to slip the schedule.

On Sat, Dec 7, 2013 at 11:41 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> 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.

Actually, freeze and seal are examples. As another example, the SES startup
uses Object.getOwnPropertyNames to do a thorough walk of the initial
primordials, aside from the global object, and remove anything not on its
whitelist. If it does find something not on its whitelist that it can't
delete and doesn't know to be safe for other reasons, then it declares that
this platform cannot be made SES-safe. That's why <
https://bugzilla.mozilla.org/show_bug.cgi?id=724768#c8> was such a problem

for us. What the combination of non-extensible and getOwnProperties gives
us is confidence that there's nothing there beyond what we see.



> 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?

I remember I was for a time in favor of [[SetIntegrity]], and made
arguments in support of it. However, it was additional semantic state that
was approximately redundant with the state already there, and could get out
of sync with it. If now were earlier in the ES6 cycle I would be open to
reconsidering it. But it raised so many open questions that I don't think
we should reopen it unless something is broken with the current plan. If we
do reopen [[SetIntegrity]], we should decide to slip the schedule.