Stepping back for a moment, there are a lot of functions in the Enum module
that apply to maps. Are we to implement all of them in the Map module just
to avoid having to call Map.new after our various Enum calls?
The way things work at the moment is that when we need to take one item out
at a t
I have used the pattern this code wraps often and would use this
feature if it existed.
Allen Madsen
http://www.allenmadsen.com
On Sat, Jun 18, 2016 at 8:39 PM, Ben Wilson wrote:
> Well I tried to reply but my email was deleted.
>
> Long story short, successive Map.put calls are actually inferio
Well I tried to reply but my email was deleted.
Long story short, successive Map.put calls are actually inferior to walking
intermediary lists and building a new map at the end. You can read more
about it here: https://github.com/elixir-lang/elixir/pull/4415
You'll note that Map.take is actuall
Here's another implementation, using Enum.reduce, without an intermediate
list:
def map_filter_values(map, func) do
Enum.reduce map, %{}, fn {key, val}, acc ->
if func.(val) do
Map.put(acc, key, val)
else
acc
end
end
end
On Saturday, June 18, 2016 at 6:27:07 PM UTC+
Sorry, I was unclear. The example implementation was an example of how the
function would work, not how it would be implemented. I was imagining an
implementation that didn't build an intermediate list. Is building a new
map each step too expensive for this to be considered composable? There's
Your example implementation shows why this isn't really necessary. Moreover
it doesn't compose well. Consider:
map
|> Enum.filter(fn {k, v} -> key_filter(k) && value_filter(v) end)
|> Map.new
vs
map
|> Map.filter_keys(key_filter)
|> Map.filter_values(value_filter)
In the latter it starts as a
I wish there was a Map.filter_values function that would filter on keys or
values, but leave the other one intact. This seems like something that
should be in the standard library.
Example implementation of a Map.filter_values that would filter a map based
on its values, leaving the keys intact
