Hi Robert,
Thanks for your thoughts on this.
> The requirement for named function expressions (NFEs) puts a serious
> crimp in developers coding style.
This mechanism does _not_ require NFEs. You can use anonymous
functions and call the super via arguments.callee if you like, and
still get big performance improvement (and stop relying on function
decompilation, although you lose ECMA5 strict mode compliance). The
invocation syntax if you use anonymous functions is ugly enough:
var Thingy = Class.create({
nifty: function(arg) {
arguments.callee.$super.call(this, arg);
}
});
...that I would (in fact, did) suggest a helper:
var Thingy = Class.create({
nifty: function(arg) {
this.callSuper(arguments, arg);
}
});
> Before I dive into details, though, can someone please tell me why
> we're not looking at Dean Edwards old Base2 approach[1], or John
> Resig's variation on that[2]?
We should definitely consider various options. This started because I
sort of accidentally went down a road, found what I thought was a
really nifty solution, and posted asking whether others were
interested in it.
My issue with Resig's approach would be the number of introduced
closures and the slippery _super method, which has too much magic in
it for my taste. These things are subjective. It also won't perform
as well, but we're talking a small increment, and as you say trade-
offs come into play.
> I mean, come on, close your eyes, take a few deep
> breaths, and then look at it...
>
> nifty.$super.call(this, spiffy)
There are lots of constructs that look a bit alien at first. To me
this isn't one of them (and I'm no JavaScript master) but I totally
recognise that for some novices there's going to be a certain amount
of "just do it like this, eventually you'll understand why." That's
true of lots of things. A novice who doesn't know about Function#call
needs to be taught about Function#call, in my view.
If we provide a helper, it could accept either 'arguments' (for
anonymous functions) or the function instance (for named fucntions),
so this:
nifty.$super.call(this, spiffy);
...could be:
this.callSuper(nifty, spiffy);
...if we think that's more helpful. The cost is an extra function
call, which compared with the various other savings we're making isn't
a big deal.
Thanks again for jumping into this,
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com
On Sep 8, 4:11 pm, Robert Kieffer <bro...@gmail.com> wrote:
> I still have some serious reservations about this patch.
>
> Before I dive into details, though, can someone please tell me why
> we're not looking at Dean Edwards old Base2 approach[1], or John
> Resig's variation on that[2]? That general approach would seem to
> offer a good trade-off between performance and usability.
>
> ... and it's that trade-off I have reservations about. If Prototype
> is going to replace the current $super technique, it's this tradeoff
> that I would like to see a nice balance on. And with all respect to
> you, T.J., I don't think your solution has that. There's no question
> it is more performant (woot!), but I have serious doubts about it's
> overall usability.
>
> The requirement for named function expressions (NFEs) puts a serious
> crimp in developers coding style. Having to declare the functions in
> one section and then wrap them up in a returned data structure in
> another... It's nice that this style works for Prototype, and I
> appreciate the advantages, but it's not exactly commonplace (not that
> anything is). It'll definitely give more than one developer pause.
> Can I politely suggest that maybe you guys are a bit too close to the
> code and are taking the learning curve here for granted?
>
> And having to explicitly type the name of each function 3-4 times to
> define it will very quickly get tiresome. It makes writing code
> harder, and it makes refactoring it harder as well. Which means more
> prone to error; there is still no IDE that is able to automatically
> and accurately change the name of functions when declared like this.
> With all the drum-beating around here about code maintainability, I'm
> a little surprised to see this issue treated so lightly.
>
> Most importantly, the syntax for invoking a supermethod, while not
> quite as horrid as some others we've seen and discussed, is still not
> that great. I mean, come on, close your eyes, take a few deep
> breaths, and then look at it...
>
> nifty.$super.call(this, spiffy)
>
> ... .vs. the current style:
>
> $super(spiffy)
>
> ... or what the Dean Edwards/John Resig style:
>
> this._super(spiffy)
>
> I know, I know, the current style has performance issues. But for a
> lot of developers a simpler, less confusing syntax will trump that. I
> suspect most will continue to use the old $super scheme, which will
> make it much harder to deprecate than you might expect. And if the
> old $super scheme is gonna stick around for a while because the new
> scheme "ain't good enough", than at the end of the day this new code
> is just unnecessary code bloat. Certainly Prototype itself doesn't
> need it - the Ajax.* classes and Timed Observer aren't used in
> situations where $super is called so often that the incremental
> performance improvement will make a difference.
>
> Sorry, I probably should have posted this before you spent your time
> implementing your patch. Still... I hope this is a constructive gut
> check for folks.
>
> - rwk
>
> [1]http://dean.edwards.name/weblog/2006/03/base/
> [2]http://ejohn.org/blog/simple-javascript-inheritance/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
