Hello All, So I have this sealed Interface: ```sea...

# getting-started

[Iheme Tobechukwu]

Hello All, So I have this sealed Interface:

sealed interface NetworkState<out T> {
    object Loading: NetworkState<Nothing>
    data class Success<T> (val data: T): NetworkState<T>
    data class Error(val message: String?): NetworkState<Nothing>
}

I use it here:

sealed class AuthState<out T> : NetworkState<T>{
    object Completed: AuthState<Nothing>()
}

And whenever i created an instance of the NetworkState, i can also check for conditions of the AuthState in my when block which is fine. Now i want to introduce another sealed class:

sealed class TableState<out T>: NetworkState<T>{

}

But i am having trouble using this as i want it to have other child heirachies whilst also inheriting the ones from NetworkState. How do I clearly differentiate from an AuthState implementation and a TableState implementation

[Joffrey]

I'm not sure I understand the problem, could you please demonstrate with a piece of code what you would like to be able to do (even with a pseudo piece of code or a magic, non-existent function)

[Youssef Shoaib [MOD]]

Sealed interfaces may be your friend here. Also, it sounds like you actually want NetworkState: TableState and not the other way around.

[Michael de Kaste]

seems like OP wants the following:

He has a base contract for states: Loading, Success Error.

He wants to introduce types of these states like AuthState, which then has 'Completed, Loading, Success, and Error'

He now also wants something like 'TableState' with 'Loading, Success and Error'

He wants to be able to differentiate between TableState.Loading vs AuthState.Loading

[Michael de Kaste]

(or correct me if I'm wrong @Iheme Tobechukwu)

[Iheme Tobechukwu]

Yes exactly thats what i need. @Michael de Kaste.Basically NetworkState as a general dictator with properties, loading, success and error shared across all implementations. Then TablesState inherit those whilst also being able to implement its own such as Empty, Filled, and AuthState having its such as Synced, Paired and Completed e.t.c @Joffrey

[Michael de Kaste]

I don't think you can make this work without redeclaring your base states.

a general when statement needs to have the implementations redeclared within the subclass if thats how you want to check them like:

[Michael de Kaste]

when(state){
        is AuthState.Completed -> println("Completed")
        is AuthState.Success -> //This does not compile because Success is not of AuthState
    }

[Michael de Kaste]

there is no way, in Kotlin, to declare that you want something to follow a 'contract of contracts' instead of just a 'contract'
saying that a class needs to have subclasses that all implement a different interface is not something you can enforce type safely.

[Youssef Shoaib [MOD]]

Here's a way to get something close to what you want:

sealed interface NetworkState<out T>: AuthState<T>, TableState<T> { ... }
sealed interface AuthState<out T> { ... }
sealed interface TableState<out T> { ... }

[Youssef Shoaib [MOD]]

Every new XState you add needs to be added as a super interface of NetworkState

[Iheme Tobechukwu]

Thanks it does help a lot. @Youssef Shoaib [MOD] Wish there was a way to restrict what when statements can implement. Such as if youre handling objects from AuthState then youre automatically not allowed to declare any implementations from TableState and Xstate in that when block. But this still helps very much. Thanks all.

[Youssef Shoaib [MOD]]

I believe the IDE should give you warnings for that

[Joffrey]

Maybe you could avoid the entire problem by using polymorphism instead of when. What do you do, business-wise, in the when statements? Maybe you can encapsulate the behaviour of the whole when in a single function (or a few) that you can define on the parent interface, and then call on any type of instance without thinking about special cases. The additional functionality provided by the extra subclasses of some hierarchies could translate to new functions only available in those subhierachies.

[Iheme Tobechukwu]

Basically I'm listening for changes at different point in a real-time operation. Mostly involves just hiding a loading bar or navigating to a new screen. I think what led me down the rabbit hole was trying to reuse the hierarchies of my network state in different screens whilst also giving them the ability to add extra steroids of their own depending on what that screen does