Kotlin 1.4 和未来值得期待的地方
Kotlin 1.4 将于 2020 年春季推出,其开发团队在博客介绍了他们对 Kotlin 的愿景:“让 Kotlin 成为您所有工作的可靠伴侣,并是您执行任务的默认语言选择。”因此,开发团队将会让开发者在所有平台上都能使用 Kotlin。
据开发团队的介绍,Kotlin 1.4 将侧重于质量和性能。因为对现在的 Kotlin 来说,提高整体体验比添加新功能更加重要。此外,因为构建速度通常是用户最关心的问题,所以开发团队正在不断改进工具链以解决此问题。但是逐步改进跟不上生产代码库的自然增长:尽管开发团队加快了编译速度,但用户编写了更多的代码,使总体构建时间还不够短。为此,开发团队计划重新实现编译器以使其更快速。
新的编译器
新编译器实现的目标是变得更快速、统一 Kotlin 支持的所有平台,并提供用于编译器扩展的 API。这将是一项多年的工作,不过开发团队已开始好一阵子了,因此新实现的某些部分将在 1.4 中发布,可让这个过程变得更加平顺。
有些功能也已经发布了; 例如,如果开发者尝试了用于类型推理的新算法,它是新编译器的一部分。其他部分的处理方法相同。 也就是说,两种版本都将在一段时间内可用,旧版本和新版本都将处于实验模式; 当新的稳定后,它将成为默认版本。
新的前端(front-end)加速
开发团队期望新编译器提高的速度将来自新的前端实现。
为了提供一些背景信息,可以将编译想成吸收源文件并将其逐步转换为可执行代码的管道。此管道的第一步俗称为编译器的前端。它解析代码和命名、执行类型检查等。此编译器的这一部分也可以在 IDE 中使用,来高亮显示语法错误、导航到定义并搜索项目中的符号用法。这是 kotlinc
如今花费最多时间的步骤,因此开发团队希望使其更快。
当前的实现尚未完成,并且不会在 1.4 中到来。 但是,大多耗时的工作都是由它完成,因此可以预期提速的效果。基准测试(编译 YouTrack 和 Kotlin 编译器本身)表明,新前端的速度约为现有前端快 4.5 倍。
统一的后端和可扩展性
在前端完成对代码的分析之后,后端将生成可执行文件。目前有三个后端:Kotlin / JVM,Kotlin / JS 和 Kotlin / Native。前两个以往是独立编写的,没有代码共享。当启动 Kotlin / Native 时,它是基于围绕 Kotlin 代码内部表示(internal representation)构建的新基础架构的,该功能具有与虚拟机中的字节码类似的功能。
现在,开发团队计划将其他两个后端迁移到同一内部表示。因此,他们将共享许多后端逻辑并拥有统一的管道,以允许对所有目标仅执行一次大多数功能、优化和错误修复。
虽然正逐步迁移到新的后端,可是在 1.4 中,默认情况下不太可能启用它们,但用户将能够选择明确使用它们。
通用的后端基础结构为跨平台编译器扩展打开了大门。可以在这管道中添加一些自定义处理和/或转换,这些处理和转换将自动适用于所有目标。在 1.4 中将不提供用于此类扩展的公开 API(该 API 稍后将被稳定),但开发团队正在与合作伙伴 (其中包括已经构建其编译器插件的 JetPack Compose )紧密合作。
新的语言功能:
Kotlin 1.4 将提供一些新的语言功能。
Kotlin 类的 SAM 转换
社区已要求开发团队引入对 Kotlin 类( KT-7770 )的 SAM 转换的支持。如果仅将一个抽象方法的接口或类预计作为参数,则将 lambda 作为参数传递时,将应用 SAM 转换。然后,编译器自动将 lambda 转换为实现抽象成员函数的类的实例。
SAM 转换当前仅适用于 Java 接口和抽象类。该设计背后的最初想法是针对此类用例明确使用函数类型。然而,事实证明,函数类型和类型别名并不能涵盖所有用例,开发者常常不得不仅在 Java 中保留接口才能对其进行 SAM 转换。
与 Java 不同,Kotlin 不允许使用一种抽象方法对每个接口进行 SAM 转换。开发团队认为,使接口适用于 SAM 转换的意图应该明确。因此,要定义 SAM 接口,开发者需要使用 fun
关键字标记一个接口,以强调它可以用作功能性接口:
fun interface Action { fun run() } fun runAction(a: Action) = a.run() fun main() { runAction { println("Hello, KotlinConf!") } }
请注意,仅在新的类型推断算法中支持传递 lambda 而不是 fun 接口
。
混合命名和位置参数
Kotlin 禁止将带有显式名称的参数(“命名”)和不带名称的常规参数(“位置”)混合使用,除非仅将命名参数放在所有位置参数之后。但是,在一种情况下,这确实很烦人:当所有参数都保持在正确的位置而您想为中间的一个参数指定名称时。Kotlin 1.4 将解决此问题,因此将能够编写如下代码:
fun f(a: Int, b: Int, c: Int) {} fun main() { f(1, b = 2, 3) }
优化的委托属性
开发团队将改进 lazy
属性和其他一些委托属性的编译方式。
通常,委托属性可以访问相应的 KProperty
反射对象。例如,当使用 Delegates.observable
时,可以显示有关已修改属性的信息:
import kotlin.properties.Delegates class MyClass { var myProp: String by Delegates.observable("<no name>") { kProperty, oldValue, newValue -> println("${kProperty.name}: $oldValue -> $newValue") } } fun main() { val user = MyClass() user.myProp = "first" user.myProp = "second" }
为了使之成为可能,Kotlin 编译器会生成一个附加的语法成员属性,即一个存储所有 KProperty
对象的数组,这些对象表示在类内部使用的委托属性:
>>> javap MyClass public final class MyClass { static final kotlin.reflect.KProperty[] $$delegatedProperties; ... }
但是,某些委托属性不会以任何方式使用 KProperty
。对于他们来说,在 $$delegatedProperties
中生成对象是次优的。Kotlin 1.4 版本将优化这种情况。如果委托属性运算符是 inline
,并且未使用 KProperty
参数,则不会生成相应的反射对象。最出色的示例是 lazy
属性。lazy
属性的 getValue
实现是 inline
,并且不使用 KProperty
参数:
inline operator fun <T> Lazy<T>.getValue(thisRef: Any?, property: KProperty<*>): T = value
从 Kotlin 1.4 开始,当定义 lazy
属性时,将不会生成相应的 KProperty
实例。如果在类中使用的唯一委托属性是 lazy
属性(以及符合此优化的其他属性),则不会为类生成整个 $$delegatedProperties
数组:
class MyOtherClass { val lazyProp by lazy { 42 } } >>> javap MyOtherClass public final class MyOtherClass { // no longer generated: static final kotlin.reflect.KProperty[] $$delegatedProperties; ... }
尾随逗号
可以在参数列表中的最后一个参数之后放置一个附加的尾随逗号,然后交换行或添加新参数,而不必添加或删除丢失的逗号。
其他主要变化
- Kotlin 1.3.40 中引入了的有用的
typeof
函数将变得稳定并在所有平台上得到支持。 - 1.3.60 版本博客文章中已经描述了使您可以在
when
内启用break
和continue
的功能。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
RetroArch 1.8.3 发布,跨平台模拟器
RetroArch 是款功能强大的跨平台模拟器,不但能够模拟许多不同的游戏主机,还能在 Windows、MacOS、Linux、Android、iOS 以及多种游戏主机上执行。目前,RetroArch 1.8.3版本已发布,更新内容如下: ANDROID / BUGFIX:修复“Install or Restore Core”回归 BUGFIX:确保在调用“drivers_init()”时始终初始化核心信息。此 bug 可能阻止核心执行内容运行时日志记录 BUGFIX / MENU:历史记录大小至少只能设置为 1 BUGFIX / MENU:(XMB / OZONE)修复了“quick menu”检测。如果XMB是通过主菜单访问的,则它不会在快捷菜单中显示保存状态缩略图 BUGFIX / CRASH / CORE UPDATER:修复潜在的双重释放错误 BUGFIX / CRASH / OPENGL / WINDOWS:修复了 1.8.2 中的回归,该回归会导致基于 GL 的内核失败,因为它会尝试错误地加载 libGLESv2.dll 而不是 OpenGL32.dll(受影响的内核:V...
- 下一篇
Git 2.25.0 发布,新特性:部分 clone 与稀疏 checkout
Git 2.25.0 发布了,项目贡献者 Taylor Blau 介绍了此版本带来的一些特性上的亮点,包括部分克隆(partial clone)与稀疏检出(sparse checkout)。 partial clone,部分克隆 一般来说,Git clone 时副本会复制仓库的所有数据,包括历史记录中每个文件的每个版本,对于非常大的存储库,如果只需要文件的一部分,那会无形中增加网络传输和本地存储的成本。在过去的几个版本中,Git 拥有了执行部分克隆的能力,这意味着它现在可以克隆并使用存储库部分内容而无需拥有所有内容。 目前该特性还处于实验阶段。 具体来讲,部分克隆需要客户端做两件事:它必须能够告诉服务器它只需要存储库中的哪些对象,同时还必须能够不与缺少完整对象集的本地存储库产生冲突。另一方面,服务器则必须能够解释客户端的请求,仅服务于某些对象,并能够生成适当的响应。 这其中必要的逻辑是需要 Git 在收到服务器的响应后能够跳过检出存储库,因为一旦检出,那么它就会发现 clone 的对象不完整,并尝试向服务器请求。实际上这一功能由另一个新特性实现:sparse checkout,稀疏检出...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS关闭SELinux安全模块
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- 设置Eclipse缩进为4个空格,增强代码规范
- Windows10,CentOS7,CentOS8安装Nodejs环境