On Aug 21, 2013, at 7:46 AM, Erik Arvidsson wrote:

> On Wed, Aug 21, 2013 at 10:07 AM, Andreas Rossberg <rossberg at google.com> wrote:
>> On 21 August 2013 15:41, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
>>> One way to think of it is that the with is acting on a view of the
>>> object that does not have the blacklisted properties. This can be
>>> implemented using proxies. I'll leave that as an exercise.
>> 
>> I see.
>> 
>>>> * How would it interact with mutation?
>>> 
>>> Another hole we didn't cover. Here is my proposal:
>>> 
>>> The @@unscopable is only accessed once, when the object environment
>>> record is created.
>> 
>> Hm, that would seem rather inconsistent with the way adding/removing
>> properties can dynamically change the domain of a 'with'. Consider:
>> 
>>  function safeenrich(o) {
>>    o.a = 1
>>    o[@@unscopable] = o[@@unscopable] || []
>>    o[@@unscopable].push('a')
>>  }
>> 
>>  let o = {}
>>  let a = 0
>>  with (o) {
>>    a  // 0
>>    safeenrich(o)
>>    a  // 1
>>  }
> 
> I don't think it is worth covering these kind of new scenarios. We are
> patching a broken feature here.
> 
> Still, it is easy to allow that if we really wanted to. We can make
> ObjectEnvironment [[HasBinding]] do object.[[Get]](@@unscopeable)
> every time then.

@@unscopable and its interaction with the with state is specified in the ES6 draft that I will release this weak 

It is specified as Erik describes, @@unscopable is only access when a with is entered.  The computability use case was designed to support doesn't involve dynamically adding properties to a with object.  Instead, the problem is inherited properties of the with object shadowing out scope bindings.

It's possible to opt-out of the mechanism via:

Object.mixin( withobj, { [@@unscopable]: [] });
with (withobj) {
   for (v of values()) ...
}

Allen

On Aug 21, 2013, at 7:46 AM, Erik Arvidsson wrote:

> I don't think it is worth covering these kind of new scenarios. We are
> patching a broken feature here.
> 
> Still, it is easy to allow that if we really wanted to. We can make
> ObjectEnvironment [[HasBinding]] do object.[[Get]](@@unscopeable)
> every time then.

@@unscopable and its interaction with the with state is specified in the ES6 draft that I will release this weak 

It is specified as Erik describes, @@unscopable is only access when a with is entered.  The computability use case was designed to support doesn't involve dynamically adding properties to a with object.  Instead, the problem is inherited properties of the with object shadowing out scope bindings.

It's possible to opt-out of the mechanism via:

```js
Object.mixin( withobj, { [@@unscopable]: [] });
with (withobj) {
   for (v of values()) ...
}
```