Function.prototype.bind

Brendan Eich brendan at mozilla.org
Wed Sep 10 11:36:37 PDT 2008


On Sep 10, 2008, at 10:24 AM, Mark S. Miller wrote:

>> Method overriding in classical
>> OOP breaks it.
>
> How? I don't understand.

It depends on the language, but your subtype method override can  
flagrantly violate my supertype method's "contract". Exceptions, non- 
termination, lots of stuff not enforced by the type system. And JS's  
dynamic type system doesn't say much about what some "apply"-named  
method might do.

But I didn't mean to digress on this point -- you're right that  
Function.apply should delegate to Function.prototype.apply.


> Rare cases that can be provided by the rare library that needs them.
> No reason to burden the API visible to all programmers.

The burden is entirely on the rare (or not so rare -- every Ajax  
library I know of) case.

There is no burden, with the right name, in Function.genericApply (or  
whatever it should be called). It's not on any prototype chain.  
Pedagogical approaches to teaching JS can reveal it later, when  
teaching the ninja secrets. Calling it a burden is like saying my  
car's automatic transmission having a fifth gear is a burden.

> Is "spread" the same as "splat"?

Yes -- spread was (Tucker, please speak up if I'm misremembering  
again) the canonical name in Dylan or CL. Splat may be a Pythonism,  
and sounds rude. For the spec's dignity we were inclined toward spread.


> Assuming they are, I agree. Unfortunately, we won't have splat in
> ES3.1, so we won't be able to simply kill 'arguments' in ES-H-strict.
> Hence the unfortunate need for tweaking it. But any static generic
> Function apply will be post ES3.1 anyway, and so discussion of it
> should assume the existence of splat.

Sounds good (so long as arguments doesn't become a full blown Array).

/be



More information about the Es-discuss mailing list