Skip to main content

Bug Tracker

Side navigation

#5995 closed feature (wontfix)

Opened January 31, 2010 04:04AM UTC

Closed July 11, 2011 09:18PM UTC

jQuery.filter inline with ES5

Reported by: rkatic Owned by:
Priority: low Milestone: 1.next
Component: traversing Version: 1.4.1
Keywords: filter,grep,es5,1.7-discuss Cc:
Blocked by: Blocking:
Description
Attachments (0)
Change History (24)

Changed June 14, 2010 12:52AM UTC by dmethvin comment:1

component: unfiledtraversing

Changed October 19, 2010 01:07AM UTC by snover comment:2

milestone: 1.4.41.5

Retarget all enhancements/features to next major version.

Changed October 19, 2010 05:56AM UTC by snover comment:3

keywords: filter, grep, es5filter grep es5 needsreview

Changed October 24, 2010 04:49PM UTC by rwaldron comment:4

priority: majorlow

Changed October 24, 2010 04:53PM UTC by rwaldron comment:5

This was also linked to from the discussion...

http://gist.github.com/290689

Changed November 11, 2010 01:49AM UTC by dmethvin comment:6

keywords: filter grep es5 needsreviewfilter grep es5

Changed November 11, 2010 02:38PM UTC by SlexAxton comment:7

status: newopen

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

Changed April 16, 2011 09:55PM UTC by john comment:8

milestone: → 1.next

Let's look at this for 1.7.

Changed May 22, 2011 07:27PM UTC by john comment:9

keywords: filter grep es5filter,grep,es5,1.7-discuss

Nominating ticket for 1.7 discussion.

Changed May 22, 2011 10:25PM UTC by rwaldron comment:10

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

Changed May 22, 2011 10:33PM UTC by rkatic comment:11

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.

Changed May 22, 2011 10:50PM UTC by rkatic comment:12

_comment0: 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 reflated one (so why not to kill two birds with one stone).1306104727465727
_comment1: 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 reflated one (so why not to kill two birds with one shot).1306104737974974
_comment2: 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 reflated one (so why not to kill two birds with single shot).1306104812493582

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).

Changed May 22, 2011 11:58PM UTC by jaubourg comment:13

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

Changed May 23, 2011 12:50AM UTC by rkatic comment:14

_comment0: 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% 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.1306112319370797

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.

Changed May 23, 2011 01:59AM UTC by ajpiano comment:15

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

Changed May 23, 2011 03:01AM UTC by timmywil comment:16

+1, I'm ok with it

Changed May 23, 2011 03:39PM UTC by danheberden comment:17

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

Changed May 23, 2011 07:07PM UTC by rkatic comment:18

_comment0: I have to apologies. I forgotten that jQuery.filter have first two arguments swapped :( \ \ So yea, making jQuery.filter inline with ES5 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.1307236051293942

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.

Changed May 23, 2011 09:23PM UTC by dmethvin comment:19

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

Changed June 03, 2011 01:27PM UTC by john comment:20

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

Changed June 04, 2011 10:18PM UTC by addyosmani comment:21

+1

Changed June 05, 2011 01:05AM UTC by rkatic comment:22

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.

Changed June 06, 2011 03:41PM UTC by jzaefferer comment:23

-1, split apart into seperate issues

Changed July 11, 2011 09:18PM UTC by dmethvin comment:24

resolution: → wontfix
status: openclosed