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?
> Method overriding in classical
> OOP breaks it.
How? I don't understand.
> Undeclared exceptions are another hard case.
> Not that we're
> ready for inheritance with overriding in any "classes as sugar" proposal
> (yet!), and we should never add declared exceptions (please! ;-)).
> 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.
More information about the Es-discuss