pablisco
05/04/2021, 11:32 AMraulraja
05/04/2021, 11:53 AMraulraja
05/04/2021, 11:54 AMtakeMap
is not a good name for it. take
is just an impl detail of this being a zipOrNull
raulraja
05/04/2021, 11:55 AMlist.zip(list2)
, if you are just zipping your own elements or returning null if a zip
to self is not possible maybe this is zipOrNull
or zipToSelfOrNull
or whatever the std lib has as name to tuple the elements of a listpablisco
05/04/2021, 11:56 AMList
already has a zip
It would be more like a reduce or fold right?raulraja
05/04/2021, 11:56 AMpablisco
05/04/2021, 11:57 AMreduceN
?pablisco
05/04/2021, 11:58 AMreduceOrNull
🤔raulraja
05/04/2021, 11:58 AMzipWithNext
pablisco
05/04/2021, 11:59 AMreflective
zipraulraja
05/04/2021, 11:59 AMraulraja
05/04/2021, 12:00 PMpablisco
05/04/2021, 12:00 PMpablisco
05/04/2021, 12:01 PMzipWithNext
returns a list with the values calculated from adjacent elementsraulraja
05/04/2021, 12:02 PMraulraja
05/04/2021, 12:03 PMpablisco
05/04/2021, 12:03 PMfoldN
may be more accurate as they would be:
(List<A>, (A) -> R) -> R?
(List<A>, (A, A) -> R) -> R?
...
raulraja
05/04/2021, 12:04 PMzipWithNext
where on each one an additional function argument is implementedraulraja
05/04/2021, 12:04 PMraulraja
05/04/2021, 12:04 PMraulraja
05/04/2021, 12:06 PMraulraja
05/04/2021, 12:08 PMraulraja
05/04/2021, 12:09 PMpablisco
05/04/2021, 12:09 PMlist.take2()?.fold { a, b -> ... }
It would add an extra type in the middle but I can see other cases where having the size codified on the type could be useful, perhapspablisco
05/04/2021, 12:17 PMraulraja
05/04/2021, 12:44 PMraulraja
05/04/2021, 12:44 PMraulraja
05/04/2021, 12:44 PMraulraja
05/04/2021, 12:45 PMraulraja
05/04/2021, 12:48 PMraulraja
05/04/2021, 12:48 PMpablisco
05/04/2021, 1:08 PMval result = nullable {
val a = list.getOrNull(0).bind()
val b = list.getOrNull(1).bind()
"$a $b"
}
When we get multiple receivers we could create something like List.bindAt(index: Int)
I think there is room for both a n-arity solution like DestructuredInvoke
as well as more concrete ones for small arities. Like:
value class SingleList<T>(val first: T) {
fun component1(): T = first
}
value class SingleList<T>(
val first: T,
val second: T,
) {
fun component1(): T = first
fun component2(): T = second
}
pablisco
05/04/2021, 1:10 PMpablisco
05/05/2021, 8:24 AMval result: Result<String> = list.iterating {
val a = next()
drop(2)
val c = next()
"$a $c"
}
More flexibility and infinite arity 😅
I’m open to better names though 🙂raulraja
05/05/2021, 9:09 AMpablisco
05/05/2021, 9:12 AMResult
with an exception in it. Initially I thought we could return a null
but I thought that this way we can communicate where the error happened. And then people can decide to convert to a null or handle the exception. The downside is that we would be throwing an exception. Alternatively, we could have iteratingOrNull
that skips the exception throwing if it’s not needed.
Btw, the next()
is not the next from Iterator
but rather a function defined in the receiver scope of iterating
forgot to mention 😅pablisco
05/05/2021, 9:15 AMiteratingOrEither
for non exception handling of the result 🤔 Problem here is that we have to create wrapper.
Or maybe have the default return an Either and then the user can convert it to a Result if they need to. Open to any of these options or all at the same time, not sure what’s best 🙂raulraja
05/05/2021, 9:15 AMraulraja
05/05/2021, 9:15 AMpablisco
05/05/2021, 9:18 AMEither<IterateError, T>
or null
respectively may be the best solution. A wrapper (Either) is probably better than throwing an exception for sure. I’ll see if I get some time this week to try somethingraulraja
05/05/2021, 9:23 AM