On 21 August 2013 16:46, Erik Arvidsson <erik.arvidsson at gmail.com> 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:
>>> 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.

I understand, but when the intent is to patch something, then I think
that the semantics of the patch should be in sync with the thing it's
patching.

Here is a not completely unlikely scenario where it might matter:

* Some library author thinks it's a good idea to monkey-patch
Object.prototype and extends it with a new method. He is aware of the
danger of doing so, so wants to play nice(r) by making the extension
unscopeable.

* Some application uses the aforementioned library. In another part it
has a 'with' statement that contains a call to some function that can
trigger lazy loading of the library under certain circumstances.

With the problem being as dynamic as it is, I think the workaround
should be equally dynamic.

/Andreas

On 21 August 2013 16:46, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
> I don't think it is worth covering these kind of new scenarios. We are
> patching a broken feature here.

I understand, but when the intent is to patch something, then I think
that the semantics of the patch should be in sync with the thing it's
patching.

Here is a not completely unlikely scenario where it might matter:

* Some library author thinks it's a good idea to monkey-patch
Object.prototype and extends it with a new method. He is aware of the
danger of doing so, so wants to play nice(r) by making the extension
unscopeable.

* Some application uses the aforementioned library. In another part it
has a 'with' statement that contains a call to some function that can
trigger lazy loading of the library under certain circumstances.

With the problem being as dynamic as it is, I think the workaround
should be equally dynamic.