On Wed, Sep 10, 2008 at 12:49 AM, Brendan Eich <[EMAIL PROTECTED]> 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
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
