On Mar 15, 9:06 am, Robert Kieffer <bro...@gmail.com> wrote:
> On Mar 14, 8:24 am, kangax <kan...@gmail.com> wrote:
>
> > Why not combine two?
>
> > ...
> > function() {
> > if (arguments.length) {
> > var ll = arguments.length;
> > args.length = l + ll;
> > while (ll--) {
> > args[l+ll] = arguments[ll];
> > }
> > }
> > return fn.apply(context, args);}
> > }
>
> This implementation won't work. "args.length" must be set for each
> call. Failure to do so will result in bugs like this (since args is
> shared across method calls):
>
> foo = someFunc.bind(1,2)
> foo(3) // calls someFunc(1,2,3)
> foo() // also calls someFunc(1,2,3)! (args unchanged from before)
>
> Thus, you have to move the "args.length=" assignment above the if
> block:
>
> > function() {
> > var ll = arguments.length;
> > args.length = l + ll;
> > if (ll) {
> > while (ll--) {
> > args[l+ll] = arguments[ll];
> > }
> > }
> > return fn.apply(context, args);}
> > }
>
> ... and since "if (ll)" is redundant with "while (ll--)", you can get
> rid of it:
>
> > function() {
> > var ll = arguments.length;
> > args.length = l + ll;
> > while (ll--) args[l+ll] = arguments[ll];
> > return fn.apply(context, args);}
> > }
>
> ... which, is the implementation I proposed in my previous post.
Understood.
>
> Regarding your point about the 4 possible outcomes. We're not
> disputing the implementation for cases 1 or 2 - it's cases #3 and #4
> that are what we care about, both of which end up having to run thru
> the above code. Given this, my claim about this being a tradeoff
> still stands. Reusing the 'args' array is faster if arguments are
> passed, but is slower if they aren't, because you have to take the
> time to do "args.length=..." in either case. My performance tests
> show this, and I still think it's a good tradeoff to make.
Yes. As I said before, this is a good optimization of partial
application (cases #3 and #4). I like it and I don't have problems
with it being in a Prototype. All I'm saying is that optimizing cases
#3, 4 is not as important as optimizing cases #1, 2, as these are the
most widely used ones. Of course, it doesn't make your optimization
any less useful for a particular use case.
Tobie, are you OK with these changes?
>
> Regarding the viability of "bindAsEventListener", I see that as a
> separate discussion. The kind of performance tweaks we're talking
Yes, we need a new thread for that.
> about just don't matter that much where bindAsEventListener is used
> (since it's unlikely event listener functions will be called more than
> a few dozen times per second.) That said, I do agree that it is a bit
Actually, frequent event listeners (mousemove, mouseover, mouseout,
scroll, resize, etc.) are called quite often. I never use Prototype's
bind on them, for example, as it slows things down noticeably. It's
just that `bindAsEventListener` is practically useless, since you
rarely want to curry arguments over event listeners.
> of a wart on the Prototype API.
>
> On the more general topic of binding arguments, Prototype has gone
> down a bit of a bad path with all of this. I've never seen a real
> need for this support in the bind() method. It's just as easy to bind
> values via closure context as it is to do using bind():
We already discussed the issues of binding earlier in this thread : )
>
> var a = 1, b = 2;
> var foo = function() {
> // reference something with a & b
> }.bind(obj);
Now imagine `foo` is declared non-locally (in a different execution
context)
>
> This code would clean up nicely if Prototype deprecated support for
> argument binding. Not that that's gonna happen. I'm just saying. :-)
This is very unlikely. ES3.1 `Function.prototype.bind` does partial
application. When browsers implement `bind` natively, it will be easy
to delegate Prototype's bind to native one (or replace it altogether)
--
kangax
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
