Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at
Mon Oct 21 04:44:40 PDT 2013

Hey everyone.

I've talked to about 100 developers whose primary language is JS this last
week (although I admit it was not a balanced survey, mainly people I know).
Most of them (Over 80) do not feel that the problem I've mentioned before
in scoped method extensions is a real problem they have to solve.

The main argument was that  polyfilling (and as Brendan put it
"prollyfilling") was good enough when not writing a library.

I am now convinced that he syntax overhead makes it not worth it in
JavaScript. I don't know how "talking to developers" works here or how it
is weighted, but I think it gave me a pretty good indication.

Thanks a lot for this discussion, I've learned a lot. Sorry if I wasted
someone's time.

Benjamin Gruenbaum.

On Wed, Oct 16, 2013 at 1:04 AM, Brendan Eich <brendan at> wrote:

>  Benjamin (Inglor) Gruenbaum <mailto:inglor at>
>> October 15, 2013 2:00 PM
>> I think I misunderstood `::` before. if `a::b(x_1,...,x_n)` _just_ means
>> `b(a,x_1,...,x_n)`
> No, rather: `, x_1, ..., x_n)` but with the original
> (not any shadowing
>  I think it might be a good solution to the chaining problem.
>> 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.
> Indeed static methods with |this| uncurried are easier to call in the
> absence of ::, and this is why I added these so-called "static generics" to
> SpiderMonkey:
> js> a = [1,2,3]
> [1, 2, 3]
> js>, x => x*x)
> [1, 4, 9]
> js> Array.reduce(a, (r,x) => r*x)
> 6
> js> // etc.
> Doing [], mapfun) or worse,**arraylike,
> mapfun) is just no fun!
>  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()`
> This is based on your misunderstanding corrected above -- :: binds the
> object to the left of :: to |this|, not to the first argument.
>  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.
> I don't see purr on Cat.prototype --what am I missing?
> Anyway, as Russell proposed, :: with imported *methods* (not |this|-free
> functions) is does call the named function, so without multimethods or any
> kind of dispatch based on arguments not receiver (this), you're right. You
> bind a method value to a name and call it on a given |this|.
> Allen objected that this doesn't do receiver-based dispatch, which I think
> was your point with the cat and kitten. That's true, and SOE has that
> advantage -- kind of. SOE as I understand the strawman looks in the
> extension object first, and the extension object has no protototype object.
> It's flat. If you use an extension name on some other object that is not
> extended, of course you get polymorphic receiver-based dispatch.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list