On Sep 24, 2009, at 2:56 PM, Charles Jolley wrote:
Now the question is, how can ClassB.foo() call ClassA.foo() in a
generic fashion?
I could force developers to hard code this knowledge (i.e. when
implementing ClassB.foo() you have to explicitly call
ClassA.foo.apply(this)) but this is prone to developer error and
also makes the code not easily transportable from one method to
another; violating the sort of "copy-and-paste" ethos that is part
of JavaScript.
I've been told that I could name the functions. e.g.:
ClassB = ClassA.extend({
foo: function foo() {
// ..code
}
});
Somehow that should solve my problem, though I can't really work out
how. But regardless, asking developers to name each method twice in
the declaration is also error prone and fragile.
--
The way I solve this currently is to implement extend() so that when
it copies an overloaded method, it sets a property ("base") on the
Function to point to the Function it is overloading. In the example
above, for example, this means that ClassB.foo.base === ClassA.foo.
This way I can write a generic call to "super" like so:
ClassB = ClassA.extend({
foo: function() {
arguments.callee.base.apply(this, arguments); // calls super!
// other code
}
});
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
}
});
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.
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.
--Oliver
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
