Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at
Mon Oct 14 13:10:51 PDT 2013

I think I had a problem articulating my thoughts in this last one.

I was trying *not* to tie my cart in front of the horse. Even before
worrying about implementer performance issues which sound important I
wanted to know if:

The problem I had was a real problem to other developers too
and it was a big enough problem for people to care about.

I'll gladly try and possibly fail in coming up with a coherent and
contained design. I wasn't looking for a solution yet, (and there are
probably people here with more clever solutions - but I'll gladly give it
my shot) at this stage I'm merely trying to assert if scoped extension
methods solve a real problem people have in JavaScript.

> I said implementors objected. How did you miss that?

I didn't. I read everything you and other people wrote about it - It was an
interesting read too. I'm just not convinced that it's _the_ blocking issue

> 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.

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.

On Mon, Oct 14, 2013 at 10:55 PM, Brendan Eich <brendan at> wrote:

> Benjamin (Inglor) Gruenbaum <mailto:inglor at>
>> October 14, 2013 12:37 PM
>> On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich <brendan at<mailto:
>> brendan at>> wrote:
>> > So, see the**papers/Berg03aClassboxes.pdf<>work, which inspired Ruby refinements as well as the scoped object
>> extensions strawman, and try to come up with compile-time-complete
>> resolution.
>> Wait a minute, does this mean that the /major/ blocking step in this
>> proposal is the speed?
> Not just the performance hit, also the complexity, as Andreas and I
> independently wrote. Extra parameters refract through internal APIs, they
> impose not only speed costs but also bug habitat and unwanted degrees of
> freedom in general. They cost.
> A compile-time solution will require something new, syntax and semantics,
> to confine the complexity. Do that, and then let's talk.
>> Are we in agreement that given the performance issue is solved we:
>>  a) Want this sort of feature/ability in the language with the extra
>> syntax it entails at all?
> Andreas also reminded me that the strawman had semantic design issues too.
> We can dredge those up if need be, but I think not yet.
> Not everyone wants "this" in some single, well-designed sense that merely
> imposes a speed reduction when used. Again, the complexity hits all paths
> in engines. The slow paths could be reoptimized but the hit is to the
> entire object model, not just in certain lexical scopes but via the heap,
> in all objects.
>   b) Want it enough to ask browser vendors actually implement it in their
>> JS engines?
> Again, there is no well-specified "it" yet.
>   c) Want it enough to actually write down a clear scope resolution
>> algorithm that decdes when to choose extension methods?
> Aha, here is the horse that goes in front of the cart.
> Do this first, call it step (a), worry about (b) and (c) later.
> Thus your "wait a minute" does not make sense. We're waiting for a
> coherent and contained design, one that doesn't hit object model and engine
> perf all over the map, and one that hangs together on its own.
>> Because I thought that the problem you've had with it is that it creates
>> more confusing scoping /to the user./
> I said implementors objected. How did you miss that?
> But there were design issues too.
> And in general, as we discovered with the 'private foo;' part of the
> original private names proposal, user confusion or complexity remains an
> objection. See my previous post.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list