Is there a way to create a an expected class that could be either a class or an abstract class in di...

# multiplatform

[Jack Darlington]

Is there a way to create a an expected class that could be either a class or an abstract class in different platforms

For example,

expect abstract class Thing {

}

actual class Thing {

}

actual abstract class Thing {

}

Obviously the example above doesn't make sense, but it does if you are trying to typealias to already existing code. It is not a huge issue, but just wondered if it existed already

[Stan Potemkin]

Can you please describe your situation so why do you actually need the abstract not everywhere?

[Jack Darlington]

Let's say I have a iOS and Android version of a library

They provide two simple classes:

Swift:

class SwiftVersionOfSomething {
fun test(): String {
return "hi"
}
}

Android:

abstract class KotlinVersionOfSomething {
func test(): String {
return "hi"
}
}

I need the value of X on both, so in my common module I create. I have no control how they are instantiated and purely just need to access the x value for both

It would be useful if I could do something like

expect <Object_With_function> SharedVersionOfSomething {
fun test(): String
}

actual typealias SharedVersionOfSomething = KotlinVersionOfSomething

actual typealias SharedVersionOfSomething = SwiftVersionOfSomething

So basically, we just say we need some object of any type that has a particular function / variable regardless of type (class/abstract class/data class/object)

[Stan Potemkin]

So what about declaring interface?

[Jozef Matus]

@kpgalligan talked about empty type-aliases to combat similar issue on Firestore if i remember corectly

[kpgalligan]

If you're trying to map classes between platforms to bridge an api, they tend to be similar but are unlikely to align exactly, so typealiases are difficult. You wind up with a preferred platform and a delegate on the other, generally speaking. To get around that, for the firestore, I implemented methods with expect extension functions rather than defining them on the expect class itself. You might be able to achieve something similar with inline classes, but haven't looked at it too much lately.

[kpgalligan]

There's a lot to describe and probably better to watch the video: https://vimeo.com/371460823

[Jack Darlington]

great, thanks for all the information, will have a go at what you suggest. I just ended up with a class for each which just is a layer between common code and platform code.