3

在 kotlin vesion 1.3.0 中，开发人员可以使用内联类。

“普通”内联类被承诺在运行时不是真正的对象，而仅在编译时存在以进行类型检查。

所以例如

inline class MyWrapper(val someString: String)

fun consumeMyWrapper(myWrapper: MyWrapper)

应编译为等效于以下内容的java：

public void consumeMyWrapper~blabla(String myWrapper)

然而，这也有效：

interface A {

    fun doJob(b: B)
}

inline class C(val self: D): A {

    override fun doJob(b: B)
}

所以我想知道这究竟是如何编译的。我不知道bytecode，所以我要求一般原则。

但是，如果这样一个应该实现某个接口的对象在运行时不存在，那么其他人必须实现该接口。它会成为内联类的接收者吗？如果接收者碰巧是不可修改的类型（例如来自其他已经编译的库）会发生什么？

我有这些担忧的原因与我最近偶然发现的一个问题有关。我需要一种更简洁的方式来Fragment与Activity大型项目进行交流。旧的方式只是说activity as? MainActivity这不是“很干净”。所以我定义了这个接口：

interface ActivityDelegate {

    val view: View

    val routing: Routing

    interface View {
       // All common view related stuff
    }

    interface Routing {
       // BottomNavigtion related stuff
    }
}

并实现如下：

class MainActivity : Activity(), ActivityDelegate {

    override val view by lazy { MainActivityView(this) }

    override val routing by lazy { MainActivityRouting(this) }
}

internal inline class MainActivityView(val self: MainActivity): ActivityDelegate.View 

internal inline class MainActivityRouting(val self: MainActivity): ActivityDelegate.Routing

我将这种方法与内联类一起使用，将一些逻辑从 MainActivity 中移出并委派职责。

所以我担心的是在这里有内联类是否合适。在这种特定情况下使用时会有所不同吗？

4

1 回答 1

3

“普通”内联类被承诺在运行时不是真实的对象

不完全的：

但是，有时需要保留包装器。根据经验，内联类在用作另一种类型时都会被装箱。

特别是，实现接口的是内联类本身。当您将内联类与接口一起使用时，静态类型正是它被装箱的情况之一（如上面链接的示例所示）。在您的情况下，我相信它会装箱并且您不会从中获得任何好处inline。

于 2019-12-17T07:23:07.350 回答