Using inline classes with expect doesn t let me use `val` wi kotlinlang #multiplatform

with “Inline class cannot have properties with backing fields”, even if all implementations provide getters. Is there a way to do this? Next step is to try the vals as extensions.

-.kt

youtrack 5

rharter

07/23/2019, 4:10 PM

Haven't tried, but could you do something like this?

Copy code

expect val id: String get()

kpgalligan

07/23/2019, 4:24 PM

I tried some permutations of that. Working on another approach now which is so far 100% not working. This is less about this issue than about learning some techniques to do this with any library. Saw you issue comment in the native repo on multiple framework deployments. We’re actually talking to potential clients about SDK work. This case in particular is Firestore. Just doing that app work with a client, but wanted to see if I could make a really solid shared sdk on top of the native. It’s close and super frustratingly not at the same time.

Running into other interesting realities. SDK’s defined on different platforms will often have the same name for functions, but will return different things. In the case of Firestore, when I call

document()

on the store, I want a

DocumentReference

. That was a typealias originally, but I changed that to be an inline wrapper in the hopes that I could clean up the interface a bit. However, on the JVM,

document()

resolves to the actual firestore

DocumentReference

and not my wrapper. You can only use the same name for things if all clients return the same thing. If your wrapper tries to return something different, the IDE might think it’s OK, but it’s not.

Good times.

By “same name” I mean “same signature”, to be more precise. The end result is the sdk has a lot of underscores in it but accomplishes the same goal, and is reasonably discoverable by the IDE

The ugly question is maybe in cases like this there should be a common prefix, like “mpData” instead of “data_“, but that’s it’s own brand of terrible.