<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Given your example, a named function expression would do the job trivially:</div><div><br></div><blockquote type="cite"></blockquote>ClassB = ClassA.extend({<br><blockquote type="cite"></blockquote><font class="Apple-style-span" color="#144FAE"><br></font><blockquote type="cite"></blockquote>&nbsp;&nbsp;foo: function foo() {<br><blockquote type="cite"></blockquote>&nbsp;&nbsp; &nbsp;foo.base.apply(this, arguments); // calls super!<br><blockquote type="cite"></blockquote>&nbsp;&nbsp; &nbsp;// other code<br><blockquote type="cite"></blockquote>&nbsp;&nbsp;}<br><blockquote type="cite"></blockquote><font class="Apple-style-span" color="#144FAE"><br></font><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>});</div></div></div></blockquote><br></div><div>This works but, as I said, this approach has a couple of drawbacks:</div><div><br></div><div>1. The function has to be named twice (foo: function foo()). &nbsp;This makes the code harder to read (especially with long names) and its not very developer-friendly since its pointless cruft.</div><div><br></div><div>2. This is also fragile. &nbsp;If you forget the second name, the code would still parse but it will be seriously broken. &nbsp;Additionally, if you decided to rename the function you would also have to edit the code on the inside. &nbsp;Hurts the "copy and paste" aspect of it.</div><div><br></div><div>In general I think this particular approach is not developer friendly enough.</div><div><br></div><div>--</div><div><br></div><div><div><blockquote type="cite">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.</blockquote></div><div><br></div><div>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. &nbsp;</div><div><br></div><div>I would rather have a way to get at the currently running function w/o having to go through arguments. &nbsp;I have no love lost with arguments. :-)</div><div><br></div><div><br></div><div></div></div><blockquote type="cite"><div><div>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.</div></div></blockquote><div><br></div><div>True. &nbsp; My assumption is that strict mode is defined so that you can continue to run older code until you can transition it. &nbsp;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. &nbsp;</div><div><br></div><div>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.</div><div><br></div><div>-Charles</div><div><br></div></body></html>