Is there any better way to cast nested Option like...

# arrow

[Venkat]

Is there any better way to cast nested Option like below.
Option<Option<List<pair<String, Option<String>>>>

[Bob Glamm]

Start with .flatten to make it Option<List<Pair<String, Option<String>>>, and then maybe describe more about the use case?

[Bob Glamm]

Depending on what you want the outcome to be it may be possible to use .traverse or .sequence to get to Option<List<Pair<String, String>>> or even Option<Map<String, String>>

[Venkat]

I Just wants to access the right most Option<String> value

[Venkat]

Flatten is not available for option. FlatMap is available

[Bob Glamm]

.flatMap { it } == .flatten

[Bob Glamm]

Do you want to go from Option<Option<List<Pair<String, Option<String>>>> to List<String>?

[Venkat]

Actually I'm writing test cases that needs to verify the value inside the string

[Venkat]

So I have to cast way those Options to compare that string with my test string value

[Bob Glamm]

.flatMap { it }.getOrElse(emptyList()).map { it.right() }.sequence().getOrElse(emptyList()) == listOf(/* expected */) should at least be in the ballpark

[Bob Glamm]

To be honest, though, that type signature is .. difficult .. at best to work with. Usually there are intermediate transformations that deal with reducing the complexity of the type signature into something easier to work

[Venkat]

I already thought of doing like this but replacing None with empty list shadows the usage of Option

[Bob Glamm]

Also, with this little context it's hard for me to suggest an efficient reduction or comparison for a test

[Venkat]

Yes understood thanks 👍

[raulraja]

There is no advantage of using Option over nullable types unless you are using polymorphism to target Option or a related transformer

[raulraja]

like OptionT

[raulraja]

the only big diference is that in nullable types there is no flatMap or flatten because the environment already forbids from ??

[raulraja]

but let and others are the same as map over option but in nullable types

[Bob Glamm]

Will arrow-meta have a syntax for comprehensions over nullable types?

[raulraja]

nullable types or suspension or other lang features that bakes a monad removes the need fro all the combinators up to Async

[raulraja]

we can add that syntax already over nullable types if we wanted with suspension if you mean this:

[raulraja]

val fa: A? = TODO()
val a: A by fa

[Venkat]

@raulraja yes, I need to figure out a way to remove some level of nested option

[raulraja]

@Bob Glamm all strict monads can shortcircuit a suspended continuation via their fold and if the unbiased casedis found raise an exception that the continuation handles itselfs and in this case would return null

[Bob Glamm]

yes, that's exactly what I was hoping

[raulraja]

we are removing the way binding happens

[raulraja]

delegating to flatMap for all strict monads specializing it and making that faster

[raulraja]

@Venkat you can eliminate the nesting of option in your expression inside an Fx block

[Venkat]

Ok let me try

[raulraja]

val fa: Option<A> = TODO()
Option.fx { 
  val a = !fa
  ... continue unfolding your nested list here
}

[raulraja]

and ! every Option

[raulraja]

your final result will be an option of your computation

[raulraja]

! will change to by