https://kotlinlang.org logo
#arrow
Title
# arrow
p

P A

10/15/2023, 6:12 PM
Hello Everyone, I’m working on implementing PATCH support for an HTTP API. I’m considering using Arrow’s Option type rather than implementing my own. Under PATCH, the three cases to handle are value present(update), value present but null(update by removing the existing value) and value absent(no update). Below is a short snippet of how this would work.
Copy code
data class Foo(val bar: Option<String?>)

Foo("the value".some())
Foo(null.some()))
Foo(none())

fun main() {
	when (val bar = Foo(Some("string")).bar) {
		None -> TODO()
		is Some -> TODO()
	}
}
The arrow documentation says “There are only a few cases where you should use
Option
instead of nullable types, and one is the nested nullability problem.” I’m wondering if this group consider this use case a valid one or if there other aspects I should be aware of (e.g., explicitly use the
Some
or
.some()
constructor).
👍 1
m

mitch

10/16/2023, 2:09 AM
We have the same use case and that's how we implemented that internally as well.
options nest well you can also model that as
Option<Option<A>>
as well. Although conceptually I think
Option<T?>
is probably more representative because
null
here is passed as a non-absent value
👍 1
p

P A

10/17/2023, 9:15 PM
Thank you for your insight!