having a lot of trouble focusing on keys about lens HOT 8 CLOSED

Thanks!

I've been playing with that idea a bit, but the problem is that the outcome of map is a bit underdefined in that case. For example let's say you have %{1 => 2, -1 => 3} you focus on the keys and map them with &(&1 * &1) - you will get a clash and should the result be %{1 => 2} or %{1 => 3}? Nevertheless I implemented Lens.into - it's not yet released, but it's in master. You can currently treat a map as an Enumerable and then gather it back into a map like so:

iex(1)> l = Lens.all |> Lens.into(%{}) |> Lens.at(0)
#Function<34.51895681/3 in Lens.seq/2>
iex(2)> Lens.map(l, %{1 => 2, -1 => 3}, &(&1 * &1))
%{1 => 2}

It looks a bit awkward, but I think it does what you want. And sometimes your transformation will be such that it never generates conflicts, so that will be a non-issue.

from lens.

Let me know if you think this is useful - then I will have a clear conscience releasing that.

from lens.

i saw into, read all the code in master to see if i was missing anything from the docs. i'm already using this style of programming in my app, i like how it separates the logic of what to change, and how to change it very cleanly, and i like how it allows for programmatic building of focusing. going to end up forcing everyone in my company to learn this.

so, the style of key focus you show me makes me think that i may not be thinking about this the same way, or maybe my thinking about how key focus would work doesn't translate at all. your keys are pretty far from normal in the case you present. i was thinking of keys being atoms or strings, or maps or arrays or whatever. keys in maps are pretty flexible.

the simple case i was thinking of was atoms, and doing key translations.

what you show me is not a map, it's a reduce, or filter.

the closest i could get to was to focus on a parent node, and map over it's children, but then i would have to use into, because the map returned a keyword list or something.

from lens.

going to end up forcing everyone in my company to learn this.

Just don't go overboard :) If the data you're working with is small enough the cost might not be worth it.

the simple case i was thinking of was atoms, and doing key translations.
what you show me is not a map, it's a reduce, or filter.

Of course. What I'm saying is that you might be implicitly doing a "reduce or filter" if your function for translating keys is not a bijection. In this case my function &(&1 *&1) is not, and you get this effect. If instead you did &(&1 + 1) all would be well:

iex(3)> Lens.map(l, %{1 => 2, -1 => 3}, &(&1 + 1))
%{0 => 3, 2 => 2}

from lens.

what are the performance implications of this way of progamming ¿

from lens.

Frankly I don't know yet. In the project I'm using this in the performance intensive part is elsewhere and the lenses are used in a preparatory part that's complicated, but short.

from lens.

Does into solve your issue?

from lens.

Closing for now, please reopen if you need further help.

from lens.