Reconciling iteratee behaviour #1
Comments
To be clear, I'm hoping that instead of fragmentation, "Underdash 1.0" would be both "Lodash 4.0" and "Underscore 2.0". Otherwise, there's much less of a point. Explicitly requesting deep path support seems wise. |
I think deep support can be pretty easily integrated. Consider
Why not add _.map(obj, ['a', 'b', 'c']) |
I'm just not a big fan of how its currently handled in lodash (I'd prefer something more explicit like what you mentioned). I do not want to see us parsing strings (theres like 40 related issues in underscore). |
I think this is a good long term goal, but I expect for the merge to succeed we should start smaller. Both I see the starting point for this as making |
Closed by #14. |
I've been mostly silent on the merge but I think this is a great step forward. I would love to see a base platform which both
underscore
andlodash
use. For this to work, strictsemver
will be a must going forward.A major difference between
underscore
andlodash
currently is how iteratees are created. As I assume this implementation will useiteratee
in the same places both libraries currently do this may prove a major incompatibility.For instance,
lodash
'siteratee
has deep string support. Personally, I think this should be removed in v4 in favour of making the user explicitly request deep (e.g._.map(obj, _.propertyDeep('a.b.c'))
).The text was updated successfully, but these errors were encountered: