Sanctuary: pluck :: Accessible a => TypeRep b -> String -> Array a -> Array (Maybe b)

[davidchambers]

In its infancy Sanctuary was a companion to Ramda, focused on providing safe versions of unsafe Ramda functions. Sanctuary is now close to being a Ramda alternative, and provides many more functions than it once did. It's important to occasionally remove poorly defined and/or unnecessary functions so the library becomes more coherent over time, even as it grows.

pluck provides a slightly more succinct way to express a composition of map and get:

> S.pluck(Number, 'x', [{x: 1}, {x: 2}, {x: '3'}, {x: null}, {}])
[Just(1), Just(2), Nothing(), Nothing(), Nothing()]

> R.map(S.get(Number, 'x'), [{x: 1}, {x: 2}, {x: '3'}, {x: null}, {}])
[Just(1), Just(2), Nothing(), Nothing(), Nothing()]

I have several issues with pluck:

• it doesn't provide much of a readability improvement over map + get;
• we provide a shorthand for map + get but not for map + gets;
• we provide a shorthand for map + get but not for map + prop; and
• type representatives are a complex concept best referenced in as few places as possible.

If you're okay with pluck being removed from the library, vote :thumbsdown:; if you would like the function to stay, vote :thumbsup:. If in addition to keeping pluck you think we should add plucks as shorthand for map + gets, please say so. Thanks. :)

[kedashoe]

I use pluck pretty often and I think it would be missed by js devs. How about changing to map + prop version? I feel like whenever I realise I am plucking it is with known objects. So the common case would be nicely handled and if we ever needed more safety we can do map(get, xs). No type reps this way as well.

I would be :+1: for plucks.

[davidchambers]

Does it bother you, Kevin, that map + get and map + prop are both useful but we're providing a convenience function for one but not the other? Were we to make pluck equivalent to the latter we'd still be providing just one of two useful shorthands.

We could rename pluck and provide mapGet, mapGets, and mapProp, but I'd prefer to simply provide the building blocks and leave such compositions to users.

[kedashoe]

In an app I'm working on I use R.pluck 27 times (I counted! ;) pretty large app, so it's not like I'm plucking relatively that often, but I'm still getting good mileage out of it). I like providing these really simple functions for the users. pluck seems to me to be a well known function that users will ask about if it is not there. I don't see the harm in including the map + prop version. I'd prefer to go that route and then also add mapGet and mapGets later if users are asking for it.

[davidchambers]

I do think map + prop is a more common combination than map + get, so I am open to the idea of changing pluck rather than removing it.

[svozza]

I like the idea of changing to map + prop. I can do the PR if that's how we decide to go.

[davidchambers]

Go for it, @svozza. :)

[svozza]

So, if we want a good error message we can't implement this in terms of prop because we get prop's error message instead. Also, if I implement it standalone I can give the index of the item in array that has the problem.

[davidchambers]

We needn't define pluck in terms of prop, though it would be nice to reuse the logic that's currently internal to prop.