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