Is there any way to get the typealias target type ...

# multiplatform

[ansman]

Is there any way to get the typealias target type when overriding a method on a specific platform:

// Common
expect class Input

interface Foo {
  fun doStuff(input: Input)
}

// JVM
actual typealias Input = InputStream

// Use site
object : Foo {
  // I want this type to be `InputStream` when implementing this
  override fun doStuff(input: Input) {
    ...
  }
}

[Nicholas Bilyk]

Common can't see platform-specific code, so if object : Foo is in Common, it can't see jvm's InputStream. If Foo is in JVM, then you can safely do this:
``
override fun doStuff(input: Input) {
input as InputStream
}
```
The reason being that your JVM backend is what supplied actual Input, and you know it supplied InputStream as that type. (the typealias has nothing to do with it)

[ansman]

I should have mentioned that “Use site” is not in the common codebase but rather in the consumer project which is likely platform specific. Also, you wouldn’t have to cast it since input is already a InputStream. You can actually just change the argument type to be InputStream. Most of my `expect`s are internal to not pollute the global namespace but then the default implementation is red since Input is not accessible

[Nicholas Bilyk]

I assumed you couldn't change the argument type because possibly common code is what passes the argument.

[ansman]

It’s more of an IDE question I suppose. Ideally I would never want to leak my expect types to the consumer if it’s a typealias

[Nicholas Bilyk]

I guess I don't really understand what you mean by "leak your expect types".
The types for expect should be your common interface.

For input streams, buffers, things like that where you have multiple platforms, the way I typically approach it is to define a common interface in common, then take the native backend implementations, such as InputStream, Buffer, etc and write a wrapper that uses the native implementation in the 'common' way.
However, sometimes that's too much work and it's easier to do closer to what you're doing and just make up a type that always gets coerced at the platform's use site. Either way though the expect type should be however it's used in common code.

[ansman]

So for example regarding Input = InputStream. I don’t want consumers of the library to have to feel like it’s a separate type when it’s actually just an InputStream. Ideally the fact that it’s called Input in the common code should be an implementation detail and should not concern the consumers

[Nicholas Bilyk]

well, it has to be a separate type when it's common code or anything you're trying to expose to common

[ansman]

Of course, but I just wish there was a way to keep that definition from being visible to the consumer which would only see the typealias target

[Nicholas Bilyk]

oh I think I get what you're saying now

[ansman]

When implementing the interface on the Jvm it would be great if Input didn’t exist for them. I hoped making it internal would do just that and I suppose it did to some extent. But instead you get compile errors unless you manually change Input to InputStream

[Nicholas Bilyk]

yeah, I could imagine a way if common code never got compiled as its own thing, but common does get created as its own library

[Nicholas Bilyk]

I hit kind of the same thing, for almost the same place - I have a common interface for buffers, but some platform code needs the actual buffer object, so I have to cast

[Nicholas Bilyk]

I do this which has the same problem you have:

interface NativeReadBuffer<T> : ReadBuffer<T> {

	/**
	 * Returns the underlying native implementation of this Buffer. For JVM it will be an nio.Buffer object, for
	 * js it will be an ArrayBuffer
	 */
	val native: Any
}

[Nicholas Bilyk]

It would be nice if I could do soooomething like:

@JsType("ArrayBuffer")
@JvmType("nio.Buffer")
val native: Any

[Nicholas Bilyk]

make sure you have a look at kotlin's multiplatform IO library, it might have a multiplatform way of doing input streams:
https://github.com/Kotlin/kotlinx-io

[ansman]

I’d be find with a @JvmName or something like that. I don’t need to specify the full path name but rather just a typealias