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

Add _.pluckPath #161

Open
joshuacc opened this issue Jul 10, 2014 · 5 comments
Open

Add _.pluckPath #161

joshuacc opened this issue Jul 10, 2014 · 5 comments
Labels
after modules This should be postponed until after modularization (temporary label, see #220) enhancement
Milestone

Comments

@joshuacc
Copy link
Contributor

See jashkenas/underscore#712

This is a natural extension of our existing _.getPath method.

@joshuacc joshuacc changed the title Add _.pluckDeep Add _.pluckPath Jul 15, 2014
@joshuacc joshuacc added this to the 0.3.1 milestone Jul 15, 2014
@joshuacc
Copy link
Contributor Author

@fogus How are you feeling about dependencies between sublibraries these days? The most natural implementation of _.pluckPath would reuse _.getPath internally, but they belong in different sublibraries.

@fogus
Copy link
Member

fogus commented Aug 30, 2014

That's a good question that I don't have a good answer for. I do believe
it's fine in theory to add cross dependencies, but if it's a single
functional dependecy maybe we should avoid it. I don't have a good feel for
where the crossover point occurs however.

On Saturday, August 30, 2014, Joshua Clanton notifications@github.com
wrote:

@fogus https://github.com/fogus How are you feeling about dependencies
between sublibraries these days? The most natural implementation of
_.pluckPath would reuse _.getPath internally, but they belong in
different sublibraries.


Reply to this email directly or view it on GitHub
#161 (comment)
.

-- http://blog.fogus.me

-- http://github.com/fogus

@joshuacc
Copy link
Contributor Author

Okay. For now, I'll implement dependency-free. But I do believe that there would be a lot of advantages in consolidating everything into a single library that can share more internal code.

@AlphaGit
Copy link
Contributor

Would this be solved by #175 ?

@joshuacc
Copy link
Contributor Author

@AlphaGit No. The pluckPath method would operate on an array and return a new array consisting of the values found at the given path. Basically map + getPath.

@jgonggrijp jgonggrijp added the after modules This should be postponed until after modularization (temporary label, see #220) label Aug 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
after modules This should be postponed until after modularization (temporary label, see #220) enhancement
Projects
None yet
Development

No branches or pull requests

4 participants