Scoped binding of a method to an object

Brendan Eich brendan at
Mon Oct 14 13:14:52 PDT 2013

Definitely deep waters here, not one simple thing. Appreciate your 

Benjamin (Inglor) Gruenbaum wrote:
> > But there were design issues too. ... user confusion or complexity 
> remains an objection.
> Yes! This is the thing that bothers me /most/ right now about scoped 
> extension methods. Introducing additional syntax to the language seems 
> like a _huge_ objection to me, the fact that it's another thing to 
> teach programmers and another thing to keep in mind when figuring out 
> scopes when reading new code is a big deal in my opinion.

Right, that is a cost we always consider. Syntax can't be polyfilled. 
Once shipped at scale cross-browser, it ends to be "forever".

> Rick and Domenic pointed out to me that one of the bigger use cases I 
> thought having scoped extension methods solves - extending a native 
> object and not having to re-implement methods seems to be already 
> solved by the clever way in the new spec and is under work. There are 
> still interesting problems I think this solves but I'm really not 
> convinced any more that adding the extra syntax is worth it.

You mean the use of 'this.constructor' to make generic Array methods 
that create array results in ES1-5 create appropriate subclass instances?

I still thought that was a breaking change on the web, which we were not 
sure we could get away with. But I agree with you it helps, a lot. Yet, 
it doesn't solve the use-cases at which the SOE strawman was aimed.


More information about the es-discuss mailing list