What about the performance implications of creating those jQuery objects
for each call? Could you check the length property of the callback
function and only pass the jQuery object if it is actually declared to
expect 2 arguments?
What about modifying each() so that it passes three arguments to its
callback: the index, the element, and the wrapped element:
function(i, e, $e) { // e === $e[0] }
That avoids the compatibility problem, but loses the parallel with the
other methods, unless you pass both e and $e to their callback as well.
David
John Resig wrote:
> A quick example:
>
> $(".msg").each(function(i, $this){
> $(".hide", this).click(function(){
> $this.hide();
> });
> });
>
> I actually proposed this set of changes to Yehuda on IM and then had a
> back and forth as to how to best implement them. I think they actually
> hold some promise. I like this since it's relatively pain-free which
> helping to reduce extra syntax (when dealing with closures in jQuery
> it's common that you'll need to declare references to the wrapped jQuery
> set - something that this avoids).
>
> The proposal is a set of 3 changes - each change is making the second
> argument of a callback function equal to $(this).
>
> - Modifying existing callbacks that have no second argument (like
> .filter, as Yehuda mentioned).
> - Modifying event callbacks to have a second argument be $(this)
> (which, can conflict with .trigger(event, data)).
> - Modifying each callbacks to have a second argument be $(this)
> (replacing the existing second argument of this).
>
> Obviously changing the second incoming argument to
> .each(function(i,$this)) is going to require a little bit of finesse. I
> did a quick search on Google Codesearch but didn't see any immediate
> warning signs:
> http://www.google.com/codesearch?hl=en&lr=&q=
> <http://www.google.com/codesearch?hl=en&lr=&q=>\.each\%28\s*function\%28\s*\w%2B%2C\s*\w%2B\s*\%29+lang%3Ajavascript&sbtn=Search
>
> If we make a change like this I would like it to be an all-or-nothing
> proposition (having a half-baked API modification landing seems kind of
> lame) BUT it must be done in a way that we're sure won't break important
> code. (At the very least, a change like this would have to be done in a
> major 1.x release.)
>
> A quick note: It's probably important to use function(i, $this) in the
> examples (to help differentiate it from a "normal" self [which generally
> equates to var self = this;]).
>
> --John
>
>
> On Mon, Jul 20, 2009 at 11:14 PM, Yehuda Katz <wyc...@gmail.com
> <mailto:wyc...@gmail.com>> wrote:
>
> At the moment, traversal callbacks, like the ones passed to
> find/filter/etc. take a single "index" parameter. I'd like to
> propose that they are unified with .each as follows:
>
> $("div").filter(function(i, self) {
> // stuff
> });
>
> As a separate concern, I'd like to discuss changing the second
> parameter in both to be a jQuery object. Obviously, it would need to
> be done via slow deprecation for .each, but I don't think it'd break
> all that much code:
>
> $("div").filter(function(i, self) {
> // self == $(this)
> })
>
> Thoughts?
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
