Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at
Sun Oct 13 15:42:59 PDT 2013

Yeah, I don't see how it's going to happen either. Now that I get you meant
dynamic as in contrary to lexical scoping having scoped object extensions
seems very counter intuitive - especially given the direction the language
is heading.

Thanks for the discussion.

On Mon, Oct 14, 2013 at 1:36 AM, Brendan Eich <brendan at> wrote:

> Benjamin (Inglor) Gruenbaum <mailto:inglor at>
>> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list