@kangax, @tobie:

*sigh*  The "name" property _was_ in the November '08 draft (sect., 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).


> 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.


> > 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

-- 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 
For more options, visit this group at 

Reply via email to