Why have they created a new language construct for...
# kotlin-native
d
Why have they created a new language construct for this?
g
Because it's provide much more granular approach and doesn't require additional abstractions. For example you can easily mark as expected top level functions, without it you need additional layer of abstraction If interfaces + separate implementation for each platform work for your use case, just use it
But expect/actual just more powerful in some cases
d
Ok, I see that makes sense for something system level like a 'File' representation.
Where I'm following MVP pattern for iOS/Android, then platform specific implementations of
ViewContract
interface (without using `expected`/`actual`) still seems more appropriate.
g
Yes, but in case of completely separate implementation you also should have different intialization code, this may be fine in some cases, but sometimes just require more code
👍 1
Also system level calls is the main use case of actual/expect
r
expect
gives you a couple things you can’t get with interfaces, such as top-level declarations and the ability to call constructors. You also get the guarantee that there’s exactly one implementation per platform, and the “dependency injection” happens for free without you needing to manually pass implementations of interfaces anywhere. But interfaces still have all the same functionality they did before, and have the advantage that they’re much easier to mock/stub out for testing.
👍 1