Opened 13 years ago
Closed 12 years ago
#5995 closed feature (wontfix)
jQuery.filter inline with ES5
Reported by: | Robert Katić | 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
Change History (24)
comment:1 Changed 13 years ago by
Component: | unfiled → traversing |
---|
comment:2 Changed 12 years ago by
Milestone: | 1.4.4 → 1.5 |
---|
comment:3 Changed 12 years ago by
Keywords: | needsreview added |
---|
comment:4 Changed 12 years ago by
Priority: | major → low |
---|
comment:6 Changed 12 years ago by
Keywords: | needsreview removed |
---|
comment:7 Changed 12 years ago by
Status: | new → open |
---|
keeping open even though the needsreview was removed. Seems like a valid request, was there a review that occured?
comment:10 Changed 12 years ago by
-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?
comment:11 Changed 12 years ago by
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.
comment:12 Changed 12 years ago by
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).
comment:13 Changed 12 years ago by
-1, I understand the endeavor, but breaking the API for some supposed "purity" is a no-go in my book.
comment:14 Changed 12 years ago by
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.
comment:15 Changed 12 years ago by
+0, If it doesn't break BC, then I don't see why not. If it does, then i do ;)
comment:17 Changed 12 years ago by
+0, Some perf tests would be nice just to make sure filter won't take a hit
comment:18 Changed 12 years ago by
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.
comment:20 Changed 12 years ago by
+0, While it would be nice, doesn't really seem worth the breaking API change at this point.
comment:22 Changed 12 years ago by
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.
comment:24 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | open → closed |
Retarget all enhancements/features to next major version.