# multiplatform


07/23/2019, 3:53 AM
Using inline classes with expect doesn’t let me use
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.
youtrack 5


07/23/2019, 4:10 PM
Haven't tried, but could you do something like this?
Copy code
expect val id: String get()


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
on the store, I want a
. 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,
resolves to the actual firestore
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.