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 comment:1
component: | unfiled → traversing |
---|
Changed October 19, 2010 01:07AM UTC by comment:2
milestone: | 1.4.4 → 1.5 |
---|
Retarget all enhancements/features to next major version.
Changed October 19, 2010 05:56AM UTC by comment:3
keywords: | filter, grep, es5 → filter grep es5 needsreview |
---|
Changed October 24, 2010 04:49PM UTC by comment:4
priority: | major → low |
---|
Changed October 24, 2010 04:53PM UTC by comment:5
This was also linked to from the discussion...
Changed November 11, 2010 01:49AM UTC by comment:6
keywords: | filter grep es5 needsreview → filter grep es5 |
---|
Changed November 11, 2010 02:38PM UTC by comment:7
status: | new → open |
---|
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 comment:8
milestone: | → 1.next |
---|
Let's look at this for 1.7.
Changed May 22, 2011 07:27PM UTC by comment:9
keywords: | filter grep es5 → filter,grep,es5,1.7-discuss |
---|
Nominating ticket for 1.7 discussion.
Changed May 22, 2011 10:25PM UTC by 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 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 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 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 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 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 comment:16
+1, I'm ok with it
Changed May 23, 2011 03:39PM UTC by 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 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 comment:19
-1, Adding (subtracting) to rkatic for -100001. :)
Changed June 03, 2011 01:27PM UTC by 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 comment:21
+1
Changed June 05, 2011 01:05AM UTC by 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 comment:23
-1, split apart into seperate issues
Changed July 11, 2011 09:18PM UTC by comment:24
resolution: | → wontfix |
---|---|
status: | open → closed |