Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can.List.filter #683

Closed
stevenvachon opened this issue Jan 20, 2014 · 3 comments
Closed

can.List.filter #683

stevenvachon opened this issue Jan 20, 2014 · 3 comments
Milestone

Comments

@stevenvachon
Copy link
Contributor

For times when removing multiple indexes, looping in reverse order is fastest. I can't think of any other time that I use reverse loops, so instead of requesting a reverse option in .forEach(), a request is being made for a .filter() method.

list.filter( function(el, index, list)
{
    return el.attr("something") !== "poop";
}, this);

@param {function()} callback A function to call with each element of the list. Returning false will remove the index.
@param {Object} thisArg The object to use as this inside the callback.


Should we also add a can.filter()?

@justinbmeyer
Copy link
Contributor

Thanks for the suggestion. I'm gonna play devils advocate here:

You don't need to loop in reverse order to remove multiple indexes, you can use a while loop.

Calling .reverse() isn't that bad. It is pretty darn fast and won't change the limiting function of your code.

I'd rather just add a reject method to lists that would remove those items like underscore's reject

@stevenvachon
Copy link
Contributor Author

Even with a while() loop, going backwards is still faster than forwards because setting the iterator back a value isn't necessary. Great idea about the .reject() method. Original post updated.

@stevenvachon
Copy link
Contributor Author

After thinking a little more, I think that a .filter() would be better as its name suggests working both for "keeping" as well as "removing".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants