@kangax, @tobie: *sigh* The "name" property _was_ in the November '08 draft (sect. 15.3.5.4), I didn't realize they'd taken it out again, but apparently they have, it's not in the April candidate spec (which has now replaced the November draft in my reference folder).
@kangax: > Last time I checked, Resig's implementation relied on function > decompilation too, which we are trying to avoid this time. You're right, at least the version linked by Robert does. I missed that initially because it's an implicit conversion when passing the function into a regex. It also happily assumes that if "_super" appears anywhere in the method -- inside a string, as a variable name, whatever -- that you want the supercall magic wrapped around it. Finally, it tests if function decompilation works and if it doesn't, the implementation wraps the magic around *all* methods. @Robert: > > That's interesting. I started down this road precisely because I > > found the existing API flawed; > > Was it the API you found flawed, or the implementation of that API? Initially it was the API, I didn't like passing the superfunction in as an argument. That lead to my looking at the implementation behind it. -- T.J. :-) On Sep 8, 11:02 pm, Robert Kieffer <bro...@gmail.com> wrote: > On Tue, Sep 8, 2009 at 1:21 PM, T.J. Crowder <t...@crowdersoftware.com> wrote: > > > Hi Robert, > > > > > arguments.callee.$super.call(this, arg); > > > > this.callSuper(arguments, arg); > > > > "six of one, half-dozen of the other"... > > > Um, "this.callSuper(arguments, arg)" (or "this.callSuper(nifty, arg)") > > is precisely *one* argument more than Resig's "this._super(arg)", but > > without the cost of the closures and unnecessary, misleading (IMV) > > magic. It's a lot clearer than the raw syntax needed with anonymous > > functions. "Six of one, half-dozen of the other" seems a bit harsh. > > I apologize, I was being glib (hence the quotes.) But there is a grain of > truth there. Both these incantations are unintuitive in their own way. > > callSuper may have only one more argument but it's a wierd one for sure. > Especially for developers unfamiliar with 'arguments' and its 'callee' > property. Many devs will treat this as yet another piece of JS voodoo code > they have to remember - "you do it just because". And what if the super > method takes different arguments than the sub method, "Wait a minute, why am > I passing an array with 'foo' & 'bar' in it, when I only want to hand 'baz' > to the supermethod?" > > > Honestly, at this point I'm mostly worried that that we may get > > > enamored with a solution that is different, but not necessarily all > > > that much "better". More performant, yes, but at the cost of > > > usability... > > > That's interesting. I started down this road precisely because I > > found the existing API flawed; > > Was it the API you found flawed, or the implementation of that API? I think > the $super argument is a rather elegant solution. Non-standard, sure, and > lacking performance, but conceptually elegant. In essence: "If you need to > access $super, just pass it to yourself as the first argument." It's easy > to remember, and hard to screw up. > > I didn't realize you'd done a "crappy performance in supercalls" > > > thrread (I was away from this group for a while). I'd seen the > > excellent work you did with curried and bound functions, though, and > > I'm glad to hear that will be finding its way into 1.6.1. > > It wasn't a thread in this group but, rather, the blog post I did a while > back that got some attention on Ajaxian.com and that other folks ran with > for a bit on their own blogs: > > http://ajaxian.com/archives/javascript-inheritance-performance --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
