(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
<allen at wirfs-brock.com>wrote:
[...]

> Also, I'm concerned that we have been overloading the meaning of the
> [[Extensible]] state by hanging other meanings off of it, because it is the
> only "integrity state" we currently have at the object level.  For example,
> we have tentative agreement at the timevalue of Date objects can not be
> modified if [[Extensible]] is false and that RegExp.prototype.compile will
> not update an RegExp instance if [[Extensible]] is false.  Both of these
> seem like things that would be better to associate with an explicit
> "frozen" object state.
>

Another instance of the same issue in a different guise is the restriction
in Object.observe (for ES7) that you cannot obtain from a frozen object the
right to notify its observers. In this case, in order to be more
permissive, we did attach the restriction to frozenness rather than just
extensibility. However, when frozenness is a complex test for a pattern of
restrictions that may or may not be accidental, this seems weird.

In other words, if an object is purposely frozen, no problem. But let's say
that in v1 of a program, object A is non-extensible, its foo property is
non-configurable, non-writable, and its bar property is writable. A later
refactoring realizes it doesn't need the bar property, and so deletes it.
It is weird that this would break previously correct code to obtain the
right to notify observers.



> We are also, from ES5, using [[Extensible]] to control whether
> [[Prototype]] can be modified.  This is a case where I think a new state
> might be appropriate as it seems very reasonable for an object to want to
> fix [[Prototype]] but still allow own properties to be added
>

While sensible in theory, I don't think that case is worth yet another
state bit. If, like Object.observe, we had attached this restriction to
frozenness, we could not consider attaching this to an explicit frozenness
bit.


>
> 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 equivalent to
>       Object.freeze(obj)
> in terms of causing Object.isFrozen(obj) to return false.
>
> 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?
>

I know of no uses of Object.isFrozen beyond those Kevin lists. None of
these would be broken by this change.

As for the rationale for the trademark restriction, more on that in a
separate email.


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

(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
<allen at wirfs-brock.com>wrote:
[...]

> Also, I'm concerned that we have been overloading the meaning of the
> [[Extensible]] state by hanging other meanings off of it, because it is the
> only "integrity state" we currently have at the object level.  For example,
> we have tentative agreement at the timevalue of Date objects can not be
> modified if [[Extensible]] is false and that RegExp.prototype.compile will
> not update an RegExp instance if [[Extensible]] is false.  Both of these
> seem like things that would be better to associate with an explicit
> "frozen" object state.
>

Another instance of the same issue in a different guise is the restriction
in `Object.observe` (for ES7) that you cannot obtain from a frozen object the
right to notify its observers. In this case, in order to be more
permissive, we did attach the restriction to frozenness rather than just
extensibility. However, when frozenness is a complex test for a pattern of
restrictions that may or may not be accidental, this seems weird.

In other words, if an object is purposely frozen, no problem. But let's say
that in v1 of a program, object A is non-extensible, its foo property is
non-configurable, non-writable, and its bar property is writable. A later
refactoring realizes it doesn't need the bar property, and so deletes it.
It is weird that this would break previously correct code to obtain the
right to notify observers.



> We are also, from ES5, using [[Extensible]] to control whether
> [[Prototype]] can be modified.  This is a case where I think a new state
> might be appropriate as it seems very reasonable for an object to want to
> fix [[Prototype]] but still allow own properties to be added
>

While sensible in theory, I don't think that case is worth yet another
state bit. If, like Object.observe, we had attached this restriction to
frozenness, we could not consider attaching this to an explicit frozenness
bit.


>
> 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 equivalent to
>
>     Object.freeze(obj)
>
> in terms of causing `Object.isFrozen(obj)` to return false.
>
> 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?
>

I know of no uses of `Object.isFrozen` beyond those Kevin lists. None of
these would be broken by this change.

As for the rationale for the trademark restriction, more on that in a
separate email.


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