Bug Tracker

Ticket #5995 (closed feature: wontfix)

Opened 5 years ago

Last modified 3 years ago

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:
Blocking: Blocked by:

Description

Change History

comment:1 Changed 4 years ago by dmethvin

  • Component changed from unfiled to traversing

comment:2 Changed 4 years ago by snover

  • Milestone changed from 1.4.4 to 1.5

Retarget all enhancements/features to next major version.

comment:3 Changed 4 years ago by snover

  • Keywords filter grep needsreview added; filter, grep, removed

comment:4 Changed 4 years ago by rwaldron

  • Priority changed from major to low

comment:5 Changed 4 years ago by rwaldron

This was also linked to from the discussion...

 http://gist.github.com/290689

comment:6 Changed 4 years ago by dmethvin

  • Keywords needsreview removed

comment:7 Changed 4 years ago by SlexAxton

  • Status changed from new to open

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

comment:8 Changed 4 years ago by john

  • Milestone set to 1.next

Let's look at this for 1.7.

comment:9 Changed 3 years ago by john

  • Keywords filter,grep,es5,1.7-discuss added; filter grep es5 removed

Nominating ticket for 1.7 discussion.

comment:10 Changed 3 years ago by rwaldron

-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 3 years ago by rkatic

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 3 years ago by rkatic

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

Last edited 3 years ago by rkatic (previous) (diff)

comment:13 Changed 3 years ago by jaubourg

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

comment:14 Changed 3 years ago by rkatic

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.

Version 0, edited 3 years ago by rkatic (next)

comment:15 Changed 3 years ago by ajpiano

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

comment:16 Changed 3 years ago by timmywil

+1, I'm ok with it

comment:17 Changed 3 years ago by danheberden

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

comment:18 Changed 3 years ago by rkatic

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.

Last edited 3 years ago by rkatic (previous) (diff)

comment:19 Changed 3 years ago by dmethvin

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

comment:20 Changed 3 years ago by john

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

comment:21 Changed 3 years ago by addyosmani

+1

comment:22 Changed 3 years ago by rkatic

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:23 Changed 3 years ago by jzaefferer

-1, split apart into seperate issues

comment:24 Changed 3 years ago by dmethvin

  • Status changed from open to closed
  • Resolution set to wontfix
Note: See TracTickets for help on using tickets.