Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at
Tue Oct 15 14:00:50 PDT 2013

I think I misunderstood `::` before. if `a::b(x_1,...,x_n)` _just_ means
`b(a,x_1,...,x_n)` I think it might be a good solution to the chaining

I think the `.constructor` proposal as well as being able to do `::`
completely eliminates the need for extension methods in this regard. It
also behaves similarly to extension methods in C# in that it's _just_ a
static method and it could also introduce interesting options.

I'm not convinced about `::` yet but it seemed to get a lot more positive
feedback from community members I really value and bloggers I talked to
since. The (small) research I'm doing about scoped extension methods or the
problem does not seem to get nearly as good of a response.

The only issue here is:

> Which polymorphism to people want? There is a "DWIM" aspect that cannot
possibly cover all uses of, e.g., 'draw' on the right of dot.

Let's say I have a classic prototypical inheritance use case.
Cat.prototype.meow = function(){...
Kitten.prototype = new Cat()
Kitten.prototype.purr = function(){ ....

Now I have a catOrKitten object. If I define a `function purr(catOrKitten)`
and call `carOrKitten::purr()` , regardless of it being a cat or a kitten -
that function gets called. If I had an extension method on Cat.prototype,
I'd get the ""correct"" behavior for kitten who overrides that method on
its prototype.

On Tue, Oct 15, 2013 at 8:26 PM, Brendan Eich <brendan at> wrote:

> Benjamin (Inglor) Gruenbaum <mailto:inglor at>
>> October 15, 2013 12:45 AM
>> Brendan Eich <brendan at <mailto:brendan at>> wrote:
>> > We already have good motivation for :: anyway, as sugar for bind. This
>> gives relief to the OO side of the expression problem trade-off by allowing
>> lexical bindings to be composed with method calls -- beautiful. No third
>> scope axis / lookup parameter!
>> Yeah, but this doesn't solve the original problem nearly as well IMO
>> since it's suddenly different from a normal method call. Having a different
>> call operator for scoped extension methods or method invocation seems very
>> confusing and counter intuitive for developers.
> That's one-sided, though. The other side you are discounting is the
> confusion when code in the scope of the extension wants to call cowbow.draw
> not graphics.draw, but draw has been overridden on the right of dot.
> Any solution must allow programmers to say what they mean. Since new
> syntax is required even in the dot-based proposal (at the end, to declare
> the extension), the cost of an alternative to dot is not novel in the sense
> of breaking operation on downrev browsers. In other words, a compiler to
> older JS will be required in any event.
>  If I have to remember different invocation mechanics I kind of lost
>> already and I don't have the polymorphism I wanted. I completely agree with
>> Allen here.
> Which polymorphism to people want? There is a "DWIM" aspect that cannot
> possibly cover all uses of, e.g., 'draw' on the right of dot.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list