Scoped binding of a method to an object
brendan at mozilla.com
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