Function.prototype.bind

Mark S. Miller erights at google.com
Wed Sep 10 10:24:25 PDT 2008


On Wed, Sep 10, 2008 at 12:49 AM, Brendan Eich <brendan at mozilla.org> wrote:
> On Sep 9, 2008, at 11:51 PM, Mark S. Miller wrote:
>
>>> LSP is not preserved by many cases in OO languages. Is it important here?
>>
>> I think it's a valuable property
>
> It's come up before, but is it a sacred cow?

Mu?

> Method overriding in classical
> OOP breaks it.

How? I don't understand.

> Undeclared exceptions are another hard case.

How?

> Not that we're
> ready for inheritance with overriding in any "classes as sugar" proposal
> (yet!), and we should never add declared exceptions (please! ;-)).

Yup.


> I'm willing to rename Function.apply, but let's talk some more about the
> better name, and about why it matters.
>
>
>> Why ducking? If this operation is needed,
>
> Do you think it's not needed?

I do think it's not needed.


> Some method of applying callable objects that aren't functions, where the
> new method does not depend on Function.prototype.apply, is necessary in our
> experience. You could try to stick to Function.prototype.apply and add
> integrity by providing a frozen standard library object with Function in it,
> but writing Function.prototype.apply.call(callable, thisobj, argsarray) is
> painful, and frozen standard library object is bloat we may not want in any
> case, certainly not just to solve the problem David-Sarah cites.

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



> There are other ways to provide a frozen apply-any-callable function, but
> the point is that something is needed beyond the replaceable
> Function.prototype.apply slot.
>
>> I think a different name is exactly the right solution.
>
> Could you suggest a new name?
>
> LSP means none of the static generics proposed for Function should have the
> same name as their Function.prototype counterparts (apply, bind, call --
> abc). We could just mangle them all with some prefix, Garrett just suggested
> "call": callApply, callBind, callCall. Ugly, arguably less usable in
> practice than the LSP violation you point out (I'm skeptical that Function
> would ever by .apply'ed indirectly), but doable. Better name ideas welcome.

I like the idea of a general naming scheme for relating the instance
method to its static-generic equivalent. I have occasionally use an
"Of" suffix for this in some of my own code. YMMV.


> Still, if we had spread, would we be bothering with Function.apply, or with
> those pesky strict mode arguments tweaks? Food for thought. Sometimes adding
> new syntax avoids silly name mangling and unnecessary modalities.

Is "spread" the same as "splat"?

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.


-- 
    Cheers,
    --MarkM


More information about the Es-discuss mailing list