dave08
10/19/2023, 1:17 PMat(At.list(), 12) that allows to pinpoint on element #12 in a list in Optics? Maybe there's another way to do this that I'm missing?Alejandro Serrano.Mena
10/19/2023, 2:00 PMat and index in the arrow.optics.dsl packagedave08
10/19/2023, 2:04 PMindex(Index.list(), 0)
that wasn't so obvious. Why not just at(At.list(), 0) just like there is for At.set() and At.map()?dave08
10/19/2023, 2:05 PMindex(..) allows modifying that specific entry?simon.vergauwen
10/19/2023, 4:01 PMAt and Index are quite different, At works with a Lens while Index works with an Optional.
At works quite different than what you're describing for Map and Set.
At for a Set<A> looks whether an A is present, and checking if the Set contains that A or it allows you to remove it from the Set. (Lens<Set<A>, Boolean>).
At for Map<K, V> looks wheter a value is present at K, and allows retrieving or removing that value using Option<V>. So setting None removes it, and setting Some(V) updates it. (Lens<Map<K, V>, Option<V>>).
So that is extremely different from what working over an Index does.dave08
10/22/2023, 9:34 AMindex(..) is saying, if it's there, get/set/transform it, if not, nothing happens (and return none?). Whereas at(...) is pinpoint at an element, if it's there, get/modify/remove it, if not, create it?
I still don't understand why Arrow wouldn't provide a specialized index(Index.listBy { it.id }, FooId(1)) for fetching by map key or some property in an element in a Set...
But maybe I'm starting to understand why at(...) is not implemented for a list (by index at least), because we could get to invalid states like trying to remove an element in the middle of a list (thereby changing all the indices). But it could still be useful to have an at(At.listBy { it.id }, 1) where id is a property on the elements in the list...