The algorithm given in [Bug 1908, comment 2] (https://bugs.ecmascript.org/show_bug.cgi?id=1908#c2) is problematic, as a property name blacklisted by an `@@unsopables` anywhere on the prototype chain will also be blacklisted when it appears as own property of the object itself, which is undesirable. According to the [meeting notes of Sep 2013 meeting] (https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/sept-17.md#53-unscopeable), this issue was discussed, but it appears that the algorithm presented in Bug 1908 does not incorpore the needed correction.

The algorithm for `HasBinding(N)` on an object environment record should be (and it seems to have been suggested in the Consensus/Resolution section of the meeting notes, if I interpret it correctly):

1. First, check if there is a property of name `N` in the prototype chain, using `HasProperty()`;
2. then, if the property of name `N` is found and if the `withEnvironment` flag is set to `true`, look for an own `@@unscopables` property on the object of the prototype chain where the property of name `N` was found, and see if it is blacklisted there.

(I was first tempted to say that, if the property name is blacklisted, we could continue to walk deeper in the prototype chain to see if we find a non-blacklisted one; but we should not do that, as it would lead to complications on the algorithms that effectively get, set or delete such a property.)

(one more comment below)


Le 1 mai 2014 à 01:23, Erik Arvidsson <erik.arvidsson at gmail.com> a écrit :

> The algorithms in the spec bug uses an object and HasOwnProperty check instead of an array and looping from 0 to length - 1. That has a lot of benefits since there are less things that can go wrong (no getters, no toString etc).
> 
> However, we might want to change to use HasProperty instead of HasOwnProperty, and have a null prototype Object for Array.prototype[Symbol.unscopables]. The reason is that would make it easier to make these more contained.
> 
> For example, in the DOM world we want to add append to Node [*] and animate to Element. If we used HasProperty we could do something like
> 
> Node.prototype[Symbol.unscopable] = {
>   __proto__: null,
>   append: true
> };
> 
> Element.prototype[Symbol.unscopable] = {
>   __proto__: Node.prototype[Symbol.unscopable],
>   animate: true
> };
> 
> If we used HasOwnProperty we would either need to change a subclass when a superclass changes or we would need to do the more complicated solution with manually walking the prototype chain in ObjectEnvironment HasBinding.
> 
> [*] not entirely true, it would go on the ParentNode interface

With my proposed algorithm, you just need to blacklist unscopable properties on the same object where they are defined:
	
	Node.prototype.@@unsocopables = { append: true }
	Element.prototype.@@unsocopables = { animate: true }

—Claude

The algorithm given in [Bug 1908, comment 2](https://bugs.ecmascript.org/show_bug.cgi?id=1908#c2) is problematic, as a property name blacklisted by an `@@unsopables` anywhere on the prototype chain will also be blacklisted when it appears as own property of the object itself, which is undesirable. According to the [meeting notes of Sep 2013 meeting](https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/sept-17.md#53-unscopeable), this issue was discussed, but it appears that the algorithm presented in Bug 1908 does not incorpore the needed correction.

The algorithm for `HasBinding(N)` on an object environment record should be (and it seems to have been suggested in the Consensus/Resolution section of the meeting notes, if I interpret it correctly):

1. First, check if there is a property of name `N` in the prototype chain, using `HasProperty()`;
2. then, if the property of name `N` is found and if the `withEnvironment` flag is set to `true`, look for an own `@@unscopables` property on the object of the prototype chain where the property of name `N` was found, and see if it is blacklisted there.

(I was first tempted to say that, if the property name is blacklisted, we could continue to walk deeper in the prototype chain to see if we find a non-blacklisted one; but we should not do that, as it would lead to complications on the algorithms that effectively get, set or delete such a property.)

(one more comment below)


Le 1 mai 2014 à 01:23, Erik Arvidsson <erik.arvidsson at gmail.com> a écrit :

> The algorithms in the spec bug uses an object and HasOwnProperty check instead of an array and looping from 0 to length - 1. That has a lot of benefits since there are less things that can go wrong (no getters, no toString etc).
> 
> However, we might want to change to use HasProperty instead of HasOwnProperty, and have a null prototype Object for Array.prototype[Symbol.unscopables]. The reason is that would make it easier to make these more contained.
> 
> For example, in the DOM world we want to add append to Node [*] and animate to Element. If we used HasProperty we could do something like
> 
> ```js
> Node.prototype[Symbol.unscopable] = {
>   __proto__: null,
>   append: true
> };
> 
> Element.prototype[Symbol.unscopable] = {
>   __proto__: Node.prototype[Symbol.unscopable],
>   animate: true
> };
> ```
>
> If we used HasOwnProperty we would either need to change a subclass when a superclass changes or we would need to do the more complicated solution with manually walking the prototype chain in ObjectEnvironment HasBinding.
> 
> [*] not entirely true, it would go on the ParentNode interface

With my proposed algorithm, you just need to blacklist unscopable properties on the same object where they are defined:
	
	Node.prototype.@@unsocopables = { append: true }
	Element.prototype.@@unsocopables = { animate: true }