jQuery.filter inline with ES5

[Robert Katić]

​Discussion

[snover]

Retarget all enhancements/features to next major version.

[Rick Waldron]

This was also linked to from the discussion...

​http://gist.github.com/290689

[SlexAxton]

keeping open even though the needsreview was removed. Seems like a valid request, was there a review that occured?

[john]

Let's look at this for 1.7.

[john]

Nominating ticket for 1.7 discussion.

[Rick Waldron]

-1, How does this benefit the API? It sets an awkward precedence as well, will we re-order the each() args to conform to ES?

[Robert Katić]

What you mean about awkward precedence? This would not break existent jQuery.filter. The only question is if we can deprecate the inv argumnet or at least indicate in docs that it have to be a boolean.

[Robert Katić]

Another thing to precise here, is that the main reason for this change is to make jQuery.filter accept callbacks as .filter() does; so it is more about internal API consistency then ES5 related one (so why not to kill two birds with single shot).

[jaubourg]

-1, I understand the endeavor, but breaking the API for some supposed "purity" is a no-go in my book.

[Robert Katić]

Let me repeat myself: This would not break the existent jQuery.filter. In fact, if you take a look at ​http://gist.github.com/290689 you will see that the current signature is still fully supported.

If you are thinking about jQuery.grep using a no-boolean as inv argument, then for 100% back-compatibility we can do:

jQuery.grep = function( elems, callback, inv ) {
	return jQuery.filter( elems, callback, !!inv );
}

I will not push this any more. I just wont to be sure that there is no misunderstandings.

[ajpiano]

+0, If it doesn't break BC, then I don't see why not. If it does, then i do ;)

[timmywil]

+1, I'm ok with it

[danheberden]

+0, Some perf tests would be nice just to make sure filter won't take a hit

[Robert Katić]

I have to apologies. I forgotten that jQuery.filter have first two arguments swapped :(

So yea, making jQuery.filter as proposed WOULD break existent one.

I suppose this means that if there is no intention to make jQuery.filter a part of public API (enhanced alias of jQuery.grep), then this is definitely a -10000.

However, I still think it can be useful to provide such multifunctional jQuery.filter to public API, even if that would mean swapping two arguments across the jQuery code.

Regarding performances, I can do some perfs if there is still interests on this, even if there should not be significant differences.

[dmethvin]

-1, Adding (subtracting) to rkatic for -100001. :)

[john]

+0, While it would be nice, doesn't really seem worth the breaking API change at this point.

[addyosmani]

+1

[Robert Katić]

Of course there is still the possibility of making jQuery.filter inline with ES5 maintaining current signatures of jQuery.filter and jQuery.grep (without breaking BC).

​https://gist.github.com/290689#file_jquery.filter_grep_bc.js

As public API, it would works as an alias of jQuery.grep (+thisObject), but would also work as current jQuery.filter.

[jzaefferer]

-1, split apart into seperate issues