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

On Wed Apr 30 2014 at 5:53:36 PM, André Bargull <andre.bargull at udo.edu>
wrote:

>  The changes from https://bugs.ecmascript.org/show_bug.cgi?id=1908 never
> made it into the spec.
>
>
>
> On 4/30/2014 11:41 PM, André Bargull wrote:
>
>  Where do you find the spec incomplete WRT @@unscopable.  My recollection was that it was all resolved and fully specified and that I was relatively happy with the outcome.
>
>
> unscopables for the Object Environment Record is always the empty list.
> It's never populated.
>
>
>  Allen
>
> On May 1, 2014, at 3:00 AM, Erik Arvidsson <erik.arvidsson at gmail.com <https://mail.mozilla.org/listinfo/es-discuss>> wrote:
>
> >* This was never resolved and the spec is incomplete here
> *> >* On Wed Sep 25 2013 at 6:17:32 PM, Allen Wirfs-Brock <allen at wirfs-brock.com <https://mail.mozilla.org/listinfo/es-discuss>> wrote:
> *>* So here is another concern, about the scheme we agreed to last week.
> *> >* It needs to match a found own property against the possibility of an own @@unscopable property on the same object and that  object may be somewhere up the inheritance chain of the actual with object.  The means that [[HasProperty]]/[[Get]]/[[Set]] can not be used to do those resolve binding in an ObjectEnvironmentRecord because they don't tell us where the property was found.  Instead, ObjectEnvironmentRecord needs to reimplement its own property lookup using [[GetOwnProperty]] and [[GetInheritanceOf]].  However, if the with object is a proxy that means we may be bypassing the actual inheritance mechanism implemented by the Proxy's 'has'/'get'/'set' traps and that could introduce observable semantics irregularities.
> *> >* Specifying the duplicated lookup is doable but a pain.  That and the semantic issues WRT proxies makes me a lot less comfortable with the added complexity of supporting @@unscopable.
> *> >* Allen
> *
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140430/b72fefa2/attachment.html>

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