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 _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
