OMG, I did not know about filter_map, and I have needed it so many times!
I don't think it's necessary here, though, a normal filter would work, since the output is the same as the input. This would also simplify the code in several places and remove a potential gotcha from changing the value of input.
The rocket assignment is a really interesting example. I might make use of that.
{a: 1,b: 2,c: 'foo'}=>{a: Integer=>a,b: 2=>b,c:
}
That's a great example!
inputif(low_count..high_count).include?(count)
Range#cover? is better here, as it translates to low_count <= count && count <= high_count, where Range#include? is more like (low_count..high_count).any? { |n| n == cont }
Yep, you're correct that filter_map isn't technically needed here and filter would have worked. My original intent was for that to be different, but I left it to mention the function mostly.
TIL: Range#cover? - Will update later today to mention that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
OMG, I did not know about
filter_map, and I have needed it so many times!I don't think it's necessary here, though, a normal
filterwould work, since the output is the same as the input. This would also simplify the code in several places and remove a potential gotcha from changing the value ofinput.The rocket assignment is a really interesting example. I might make use of that.
That's a great example!
Range#cover?is better here, as it translates tolow_count <= count && count <= high_count, whereRange#include?is more like(low_count..high_count).any? { |n| n == cont }Yep, you're correct that
filter_mapisn't technically needed here andfilterwould have worked. My original intent was for that to be different, but I left it to mention the function mostly.TIL:
Range#cover?- Will update later today to mention that.