Scoped binding of a method to an object

Brendan Eich brendan at mozilla.com
Sun Oct 13 15:36:43 PDT 2013


> Benjamin (Inglor) Gruenbaum <mailto:inglor at gmail.com>
> October 13, 2013 2:28 PM
> Thanks, this really helped me understand the underlying issue here 
> forcing dynamic resolution of scope here. It sounds a lot harder than 
> I initially thought
>
> I have to say the fact this is so deeply rooted in the language 
> semantics is somewhat surprising to me. That said, I think I see why 
> behavioral typing would be act like this and I expect this to still be 
> a lot harder than I imagine.
>
> > Here is a counterexample based on the strawman's syntax:
> > ...
>
> When I pass a parameter `a` to a function and call `a.where` , whether 
> or not it's an extension method - don't I still have to do dynamic 
> scope resolution?

That's not "dynamic scope", first ("dynamic scope" refers to scoping 
where an *unqualified* name's meaning cannot be determined lexically -- 
e.g., with or the global object in JS; inline event handlers in the DOM).

> Doesn't it still have to walk the prototype chain until I find 
> `.where` - just like if I pass an array-like with `.splice` and send 
> it to a method using it and it has to figure out it's not 
> Array.prototype.splice?

Of course. The meaning a dot-qualified name in JS indeed depends on 
prototype lookup. But the parameters to that lookup procedure are the 
starting (directly referenced) object and the property name -- and not 
the scope in addition, or any equivalent transformation (e.g., my ?: 
example -- not also it used instanceof and did not work when a direct 
shadowing method existed on the array).

> Off the top of my head - what about for the duration of the scope of 
> these methods we  "have a prototype right after Array.prototype" - in 
> this scenario. Doesn't this make `c` go to Object.prototype.where and 
> then String.prototype.select and all `b` does is another prototype 
> chain look up before reaching the extension? This is probably another 
> naive suggestion though.

It is, if you mean dynamically altering the prototype chain of standard 
objects within a lexical extent. That does create dynamic scope, since 
the call graph is not statically decidable in general in JS, and calls 
out of the lexical extent would see the prototype chain extension too. 
Even if we could pin down the call graph, we do not want arbitrary 
mutations going in and out of scope of prototype chains.

Anyway, I think at this point we've established what is required for any 
"scoped object extensions". Please draw the conclusion.

/be


More information about the es-discuss mailing list