On 26 August 2013 23:18, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>
> On Aug 26, 2013, at 1:38 PM, Erik Arvidsson wrote:
>
>> On Mon, Aug 26, 2013 at 3:02 PM, Allen Wirfs-Brock
>> <allen at wirfs-brock.com> wrote:
>>>
>>> On Aug 26, 2013, at 11:37 AM, Erik Arvidsson wrote:
>>>
>>>> I agree that this is crucial. I think that tips the balance over to
>>>> have to do the Get of @@unscopable on every HasBinding.
>>>
>>> How so.  The timing of the @@unscopable property and the the process of using it to filter identifier binding are completely separable procedures. How does restricting the filtering to own properties  change the rationale for  getting the blacklist property once per 'with'  rather than on every variable reference.
>>
>> I just felt things got a bit too complicated to spec.
>>
>> I realize now that the complexity is not very different either way.
>>
>> I'm ambivalent which behavior I prefer. Either way solves the use case
>> but dynamic lookup has the benefit that will better handle crazy edge
>> cases like changing @@unscopable and [[Prototype]] within the with
>> statement.
>
> At the cost of turning every implicit property access within a 'with' into two property accesses (which are observable vis proxies or accessors)  even in normal cases that are far away from the crazy edges.

I would not worry about the cost -- if you want remotely decent
performance, you wouldn't use with-scopes anyway (e.g. in V8, they do
not get optimized at all, and every variable lookup already is a
runtime call). Also, it's not hard to fast-case the normal case for
objects that have no @@unscopable.

Conceptual consistency and the principle of least surprise is more
important. The potential performance cost is the honest price to pay
for having a complicated object model. I don't like trying to cheat
our way around that.

/Andreas

I would not worry about the cost -- if you want remotely decent
performance, you wouldn't use with-scopes anyway (e.g. in V8, they do
not get optimized at all, and every variable lookup already is a
runtime call). Also, it's not hard to fast-case the normal case for
objects that have no @@unscopable.

Conceptual consistency and the principle of least surprise is more
important. The potential performance cost is the honest price to pay
for having a complicated object model. I don't like trying to cheat
our way around that.