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()
?index(..)
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...