Given your example, a named function expression would do the job
trivially:
ClassB = ClassA.extend({
foo: function foo() {
foo.base.apply(this, arguments); // calls super!
// other code
}
});
This works but, as I said, this approach has a couple of drawbacks:
1. The function has to be named twice (foo: function foo()). This
makes the code harder to read (especially with long names) and its not
very developer-friendly since its pointless cruft.
2. This is also fragile. If you forget the second name, the code
would still parse but it will be seriously broken. Additionally, if
you decided to rename the function you would also have to edit the
code on the inside. Hurts the "copy and paste" aspect of it.
In general I think this particular approach is not developer friendly
enough.
--
It is likely to be both faster and safer than arguments.callee as
both arguments and callee can be overridden, and the lookup up for
'foo' is guaranteed.
Agreed on the faster side of things but, as I said, I think there are
developer-friendlyness issues with this approach that make it
unsuitable as a general solution for this pattern.
I would rather have a way to get at the currently running function w/o
having to go through arguments. I have no love lost with arguments. :-)
One other thing to consider is that arguments.callee is only invalid
in strict mode -- arguments.callee will continue to work fine in the
general case.
True. My assumption is that strict mode is defined so that you can
continue to run older code until you can transition it. in other
words, one should aspire to convert all of their code to strict mode
at some time; compatibility mode is intended just to help transition.
In that is the case, then "strict" mode should be able to implement a
common design pattern like method overloading in a friendly way,
otherwise developers may never convert.
-Charles
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
