[译]记一次Kotlin官方文档翻译的PR(内联类)

简述: 这几天忽然没更新文章了,可能有的小伙伴认为寒冬将至,是否是认为我跑路了(哈哈,确实不是哈,这几天感冒挺厉害的,再加上前几天连续熬夜写文章,感受快扛不住了,因此暂时休息停更了一周。这不这篇内联类官网文档的翻译,已经拖了不少天,今天总算给中文社区的大佬提了PR)。有些小伙伴在公众号上留言问我协程文章何时出。这几天正在写协程相关的文章了,很快就能够发布了哈。html

翻译说明:git

原标题: inline-classgithub

原文地址: Kotlin官网web

译文地址: Kotlin中文站-内联类数组

内联类

内联类仅在 Kotlin 1.3 以后版本可用,目前仍是实验性的。关于详情请参见下文性能优化

有时候,业务逻辑须要围绕某种类型建立包装器。然而,因为额外的堆内存分配问题,它会引入运行时的性能开销。此外,若是被包装的类型是原生类型,性能的损失是很糟糕的,由于原生类型一般在运行时就进行了大量优化,然而他们的包装器却没有获得任何特殊的处理。app

为了解决这类问题,Kotlin引入了一种被称为 内联类 的特殊类,它经过在类的前面定义一个 inline 修饰符来声明:maven

inline class Password(val value: String)
复制代码

内联类必须含有惟一的一个属性在主构造函数中初始化。在运行时,将使用这个惟一属性来表示内联类的实例 (关于运行时的内部表达请参阅 下文):ide

// 不存在 'Password' 类的真实实例对象
// 在运行时,'securePassword' 仅仅包含 'String'
val securePassword = Password("Don't try this in production") 
复制代码

这就是内联类的主要特性,它灵感来源于 “inline” 这个名称:类的数据被 “内联”到该类使用的地方(相似于 内联函数 中的代码被内联到该函数调用的地方)。函数

成员

内联类支持普通类中的一些功能。特别是,内联类能够声明属性与函数:

inline class Name(val s: String) {
    val length: Int
        get() = s.length

    fun greet() {
        println("Hello, $s")
    }
}    

fun main() {
    val name = Name("Kotlin")
    name.greet() // `greet` 方法会做为一个静态方法被调用
    println(name.length) // 属性的 get 方法会做为一个静态方法被调用
}
复制代码

然而,内联类的成员也有一些限制:

  • 内联类不能含有 init 代码块
  • 内联类不能含有 inner
  • 内联类不能含有幕后字段
    • 所以,内联类只能含有简单的计算属性(不能含有延迟初始化/委托属性)

继承

内联类容许去继承接口

interface Printable {
    fun prettyPrint(): String
}

inline class Name(val s: String) : Printable {
    override fun prettyPrint(): String = "Let's $s!"
}    

fun main() {
    val name = Name("Kotlin")
    println(name.prettyPrint()) // 仍然会做为一个静态方法被调用
}
复制代码

禁止内联类参与到类的继承关系结构中。这就意味着内联类不能继承其余的类并且必须是 final

表示方式

在生成的代码中,Kotlin编译器为每一个内联类保留一个包装器。内联类的实例能够在运行时表示为包装器或者基础类型。这就相似于 Int 能够表示为原生类型 int 或者包装器 Integer

为了生成性能最优的代码,Kotlin 编译更倾向于使用基础类型而不是包装器。 然而,有时候使用包装器是必要的。通常来讲,只要将内联类用做另外一种类型,它们就会被装箱。

interface I

inline class Foo(val i: Int) : I

fun asInline(f: Foo) {}
fun <T> asGeneric(x: T) {}
fun asInterface(i: I) {}
fun asNullable(i: Foo?) {}

fun <T> id(x: T): T = x

fun main() {
    val f = Foo(42) 
    
    asInline(f)    // 拆箱操做: 用做 Foo 自己
    asGeneric(f)   // 装箱操做: 用做泛型类型 T
    asInterface(f) // 装箱操做: 用做类型 I
    asNullable(f)  // 装箱操做: 用做不一样于 Foo 的可空类型 Foo?
    
    // 在下面这里例子中,'f' 首先会被装箱(当它做为参数传递给 'id' 函数时)而后又被拆箱(当它从'id'函数中被返回时)
    // 最后, 'c' 中就包含了被拆箱后的内部表达(也就是 '42'), 和 'f' 同样 
    val c = id(f)  
}
复制代码

由于内联类既能够表示为基础类型有能够表示为包装器,引用相等对于内联类而言毫无心义,所以这也是被禁止的。

名字修饰

因为内联类被编译为其基础类型,所以可能会致使各类模糊的错误,例如意想不到的平台签名冲突:

inline class UInt(val x: Int)

// 在JVM平台上被表示为'public final void compute(int x)'
fun compute(x: Int) { }

// 同理,在JVM平台上也被表示为'public final void compute(int x)'!
fun compute(x: UInt) { }
复制代码

为了缓解这种问题,通常会经过在函数名后面拼接一些稳定的哈希码来重命名函数。 所以, fun compute(x: UInt) 将会被表示为 public final void compute-<hashcode>(int x), 以此来解决冲突的问题。

请注意在Java中 - 是一个 无效的 符号,也就是说在Java中不能调用使用内联类做为形参的函数。

内联类与类型别名

初看起来,内联相似乎与类型别名很是类似。实际上,二者彷佛都引入了一种新的类型,而且都在运行时表示为基础类型。

然而,关键的区别在于类型别名与其基础类型(以及具备相同基础类型的其余类型别名)是 赋值兼容 的,而内联类却不是这样。

换句话说,内联类引入了一个真实的新类型,与类型别名正好相反,类型别名仅仅是为现有的类型取了个新的替代名称(别名):

typealias NameTypeAlias = String
inline class NameInlineClass(val s: String)

fun acceptString(s: String) {}
fun acceptNameTypeAlias(n: NameTypeAlias) {}
fun acceptNameInlineClass(p: NameInlineClass) {}

fun main() {
    val nameAlias: NameTypeAlias = ""
    val nameInlineClass: NameInlineClass = NameInlineClass("")
    val string: String = ""

    acceptString(nameAlias) // 正确: 传递别名类型的实参替代函数中基础类型的形参
    acceptString(nameInlineClass) // 错误: 不能传递内联类的实参替代函数中基础类型的形参

    // And vice versa:
    acceptNameTypeAlias("") // 正确: 传递基础类型的实参替代函数中别名类型的形参
    acceptNameInlineClass("") // 错误: 不能传递基础类型的实参替代函数中内联类类型的形参
}
复制代码

内联类的实验性状态

内联类的设计目前是实验性的,这就是说此特性是正在 快速变化的,而且不保证其兼容性。在 Kotlin 1.3+ 中使用内联类时,将会获得一个警告,来代表此特性仍是实验性的。

要想移除警告,你必须经过对 kotlinc 指定 -XXLanguage:+InlineClasses参数来选择使用该实验性的特性。

在Gradle中启用内联类:

compileKotlin {
    kotlinOptions.freeCompilerArgs += ["-XXLanguage:+InlineClasses"]
}
复制代码

关于详细信息,请参见编译器选项。关于多平台项目的设置,请参见使用Gradle构建多平台项目章节。

在Maven中启用内联类

<configuration>
    <args>
        <arg>-XXLanguage:+InlineClasses</arg> 
    </args>
</configuration>
复制代码

关于详细信息,请参见指定编译器选项

进一步讨论

关于其余技术详细信息和讨论,请参见内联类的语言提议

译者有话说

为何要翻译官方文档,其实只想向你们传递一个信息: Kotlin的官方文档确实不错,也许学会看官方文档才能让你走得更快和更远。咱们都知道学习一个新的技术,最好的方式就是看官方文档。 为何说Kotlin官方文档不错,以这次内联类举例,是否是还记得以前我翻译几篇国外大佬有关kotlin内联类的文章,能够说把内联类研究得很全面了,好比内联类自动装箱和性能优化,内联类与typealias类型别名的区别等等,能够看下其实这些官网都有提到。因此国外大佬无非也是在官网基础上对某个问题进行更深刻挖掘和探索。因此多看技术官方文档,能让你对某项技术了解的更加全面。

问题来了,可能不少人都厌倦看英文了,因此此次给你们安利一波Kotlin官方认准的Kotlin中文站、Kotlin中文博客、Kotlin中文社区

Kotlin中文站

Kotlin中文博客

Kotlin中文社区

很是欢迎热爱Kotlin的小伙伴们加入到Kotlin中文社区,若是你想为Kotlin中文站翻译文档提PR的话。你能够直接在中文站翻译github地址,找到灰蓝天际大佬便可。固然你能够直接到个人下面公众号(Kotlin开发者联盟)留言,给你引荐一波,哈哈。 若是你以为翻译不错,欢迎给个star。 私人GitHub,通常人不告诉他

欢迎关注Kotlin开发者联盟,这里有最新Kotlin技术文章,每周会不按期翻译一篇Kotlin国外技术文章。若是你也喜欢Kotlin,欢迎加入咱们~~~

Kotlin系列文章,欢迎查看:

Effective Kotlin翻译系列

原创系列:

翻译系列:

实战系列:

相关文章
相关标签/搜索