Scoped binding of a method to an object

Brendan Eich brendan at mozilla.com
Mon Oct 14 12:55:37 PDT 2013


> Benjamin (Inglor) Gruenbaum <mailto:inglor at gmail.com>
> October 14, 2013 12:37 PM
> On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
> > So, see the 
> http://scg.unibe.ch/archive/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


More information about the es-discuss mailing list