Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at gmail.com
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 mozilla.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131014/5420312a/attachment.html>


More information about the es-discuss mailing list