> Le 6 mars 2017 à 11:10, Raul-Sebastian Mihăilă <raul.mihaila at gmail.com> a écrit :
> 
> To be more explicit, the invariants allow this surprising behavior:
> 
> ```js
> Object.preventExtensions(nonStandardExoticObject);
> Object.isExtensible(nonStandardExoticObject); // false
> 
> 'foo' in nonStandardExoticObject; // false
> 
> Object.getOwnPropertyDescriptor(nonStandardExoticObject, 'foo'); // {value: 2, enumerable: true, configurable: true, writable: true}
> ```

That particular case should be covered by the following items in section [Invariants of the Essential Internal Methods] (https://tc39.github.io/ecma262/#sec-object-internal-methods-and-internal-slots)

	Definitions:
		A non-existent property is a property that does not exist as an own property on a non-extensible target.

And:

	[[GetOwnProperty]] (P)
		(last item): If the target is non-extensible and P is non-existent, then all future calls to [[GetOwnProperty]] (P) on the target must describe P as non-existent (i.e. [[GetOwnProperty]] (P) must return undefined).

However, it is true that the definition of “non-existent” property is at best vague, at worst incomplete. That is, instead of “does not exist as an own property”, it should say that one of the three following things happens, all of them are intuitively interpreted as implying that there does not exist an own property named P:

* [[GetOwnProperty]](P) returns undefined, or
* [[HasProperty]](P) returns false, or
* [[OwnPropertyKeys]]() returns a List that doesn't include P.

That said, there are other (often subtle) issues in that section. Few months ago, I have attempted a more rigorous reformulation; the motivation at that time was to check whether the integrity checks for Proxies were complete:

https://github.com/claudepache/es-invariants/blob/master/invariants.md <https://github.com/claudepache/es-invariants/blob/master/invariants.md>

In that document the notion of “non-existent property” (implied: on a non-extensible object) is translated into the lock: @exists(P): false.

However, I don’t consider it as a pressing issue, because the spirit of the section Invariants of the Essential Internal Methods seems correct, even if the letter is provably incomplete or vague.

—Claude



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170306/b5543c05/attachment.html>

> Le 6 mars 2017 à 11:10, Raul-Sebastian Mihăilă <raul.mihaila at gmail.com> a écrit :
> 
> To be more explicit, the invariants allow this surprising behavior:
> 
> ```js
> Object.preventExtensions(nonStandardExoticObject);
> Object.isExtensible(nonStandardExoticObject); // false
> 
> 'foo' in nonStandardExoticObject; // false
> 
> Object.getOwnPropertyDescriptor(nonStandardExoticObject, 'foo'); // {value: 2, enumerable: true, configurable: true, writable: true}
> ```

That particular case *should* be covered by the following items in section [Invariants of the Essential Internal Methods](https://tc39.github.io/ecma262/#sec-invariants-of-the-essential-internal-methods)

	Definitions:
		A non-existent property is a property that does not exist as an own property on a non-extensible target.

And:

	\[\[GetOwnProperty]] (P)
		(last item): If the target is non-extensible and P is non-existent, then all future calls to [[GetOwnProperty]] (P) on the target must describe P as non-existent (i.e. [[GetOwnProperty]] (P) must return undefined).

However, it is true that the definition of “non-existent” property is at best vague, at worst incomplete. That is, instead of “does not exist as an own property”, it should say that one of the three following things happens, all of them are *intuitively* interpreted as implying that there does not exist an own property named P:

* \[\[GetOwnProperty]](P) returns undefined, or
* \[\[HasProperty]](P) returns false, or
* \[\[OwnPropertyKeys]]() returns a List that doesn't include P.

That said, there are other (often subtle) issues in that section. Few months ago, I have attempted a more rigorous reformulation; the motivation at that time was to check whether the integrity checks for Proxies were complete:

https://github.com/claudepache/es-invariants/blob/master/invariants.md

In that document the notion of “non-existent property” (implied: on a non-extensible object) is translated into the lock: @exists(P): false.

However, I don’t consider it as a pressing issue, because the spirit of the section Invariants of the Essential Internal Methods seems correct, even if the letter is provably incomplete or vague.

—Claude

> Le 6 mars 2017 à 11:10, Raul-Sebastian Mihăilă <raul.mihaila at gmail.com> a écrit :
> 
> To be more explicit, the invariants allow this surprising behavior:
> 
> ```js
> Object.preventExtensions(nonStandardExoticObject);
> Object.isExtensible(nonStandardExoticObject); // false
> 
> 'foo' in nonStandardExoticObject; // false
> 
> Object.getOwnPropertyDescriptor(nonStandardExoticObject, 'foo'); // {value: 2, enumerable: true, configurable: true, writable: true}
> ```

That particular case *should* be covered by the following items in section [Invariants of the Essential Internal Methods](https://tc39.github.io/ecma262/#sec-invariants-of-the-essential-internal-methods)

	Definitions:
		A non-existent property is a property that does not exist as an own property on a non-extensible target.

And:

	\[\[GetOwnProperty]] (P)
		(last item): If the target is non-extensible and P is non-existent, then all future calls to [[GetOwnProperty]] (P) on the target must describe P as non-existent (i.e. [[GetOwnProperty]] (P) must return undefined).

However, it is true that the definition of “non-existent” property is at best vague, at worst incomplete. That is, instead of “does not exist as an own property”, it should say that one of the three following things happens, all of them are *intuitively* interpreted as implying that there does not exist an own property named P:

* \[\[GetOwnProperty]](P) returns undefined, or
* \[\[HasProperty]](P) returns false, or
* \[\[OwnPropertyKeys]]() returns a List that doesn't include P.

That said, there are other (often subtle) issues in that section. Few months ago, I have attempted a more rigorous reformulation; the motivation at that time was to check whether the integrity checks for Proxies were complete:

https://github.com/claudepache/es-invariants/blob/master/invariants.md

In that document the notion of “non-existent property” (implied: on a non-extensible object) is translated into the lock: @exists(P): false.

However, I don’t consider it as a pressing issue, because the spirit of the section Invariants of the Essential Internal Methods seems correct, even if the letter is provably incomplete or vague.

> Le 6 mars 2017 à 11:10, Raul-Sebastian Mihăilă <raul.mihaila at gmail.com> a écrit :
> 
> To be more explicit, the invariants allow this surprising behavior:
> 
> ```js
> Object.preventExtensions(nonStandardExoticObject);
> Object.isExtensible(nonStandardExoticObject); // false
> 
> 'foo' in nonStandardExoticObject; // false
> 
> Object.getOwnPropertyDescriptor(nonStandardExoticObject, 'foo'); // {value: 2, enumerable: true, configurable: true, writable: true}
> ```

That particular case *should* be covered by the following items in section [Invariants of the Essential Internal Methods](https://tc39.github.io/ecma262/#sec-object-internal-methods-and-internal-slots)

	Definitions:
		A non-existent property is a property that does not exist as an own property on a non-extensible target.

And:

	\[\[GetOwnProperty]] (P)
		(last item): If the target is non-extensible and P is non-existent, then all future calls to [[GetOwnProperty]] (P) on the target must describe P as non-existent (i.e. [[GetOwnProperty]] (P) must return undefined).

However, it is true that the definition of “non-existent” property is at best vague, at worst incomplete. That is, instead of “does not exist as an own property”, it should say that one of the three following things happens, all of them are *intuitively* interpreted as implying that there does not exist an own property named P:

* \[\[GetOwnProperty]](P) returns undefined, or
* \[\[HasProperty]](P) returns false, or
* \[\[OwnPropertyKeys]]() returns a List that doesn't include P.

That said, there are other (often subtle) issues in that section. Few months ago, I have attempted a more rigorous reformulation; the motivation at that time was to check whether the integrity checks for Proxies were complete:

https://github.com/claudepache/es-invariants/blob/master/invariants.md

In that document the notion of “non-existent property” (implied: on a non-extensible object) is translated into the lock: @exists(P): false.

However, I don’t consider it as a pressing issue, because the spirit of the section Invariants of the Essential Internal Methods seems correct, even if the letter is provably incomplete or vague.

> Le 6 mars 2017 à 11:10, Raul-Sebastian Mihăilă <raul.mihaila at gmail.com> a écrit :
> 
> To be more explicit, the invariants allow this surprising behavior:
> 
> ```js
> Object.preventExtensions(nonStandardExoticObject);
> Object.isExtensible(nonStandardExoticObject); // false
> 
> 'foo' in nonStandardExoticObject; // false
> 
> Object.getOwnPropertyDescriptor(nonStandardExoticObject, 'foo'); // {value: 2, enumerable: true, configurable: true, writable: true}
> ```

That particular case should be covered by the following items in section [Invariants of the Essential Internal Methods](https://tc39.github.io/ecma262/#sec-object-internal-methods-and-internal-slots)

	Definitions:
		A non-existent property is a property that does not exist as an own property on a non-extensible target.

And:

	\[\[GetOwnProperty]] (P)
		(last item): If the target is non-extensible and P is non-existent, then all future calls to [[GetOwnProperty]] (P) on the target must describe P as non-existent (i.e. [[GetOwnProperty]] (P) must return undefined).

However, it is true that the definition of “non-existent” property is at best vague, at worst incomplete. That is, instead of “does not exist as an own property”, it should say that one of the three following things happens, all of them are intuitively interpreted as implying that there does not exist an own property named P:

* \[\[GetOwnProperty]](P) returns undefined, or
* \[\[HasProperty]](P) returns false, or
* \[\[OwnPropertyKeys]]() returns a List that doesn't include P.

That said, there are other (often subtle) issues in that section. Few months ago, I have attempted a more rigorous reformulation; the motivation at that time was to check whether the integrity checks for Proxies were complete:

https://github.com/claudepache/es-invariants/blob/master/invariants.md

In that document the notion of “non-existent property” (implied: on a non-extensible object) is translated into the lock: @exists(P): false.

However, I don’t consider it as a pressing issue, because the spirit of the section Invariants of the Essential Internal Methods seems correct, even if the letter is provably incomplete or vague.