Dart获得类型系统

大家都为之欢欣鼓舞,因为Dart 2.0即将到来,并且它具有类型 。

这是Dart的第一个重大突破性变化,因此也就是“ 2”。这恰恰是因为它是一项如此重要的变化,因此是一项突破性变化。 让我们探究为什么。 首先,一些Dart 1代码:

  void main(){ 
    cleanUp([new TempFile(),new BankAccount()]); 
  } void cleanUp(List  files)=> 
      files.forEach((f)=> f.delete());  类TempFile { 
    void delete()=> print('TempFile已删除。'); 
  } Class BankAccount { 
    void delete()=> print('BankAccount delete。Whoops!'); 
  } > TempFile已删除。 
  > BankAccount已删除。  哎呀! 

该代码有点令人惊讶。

“ TempFile”和“ BankAccount”都具有“删除”方法; 碰巧的是,由于Dart 1默认情况下不关心类型,因此当我们非常清楚地尝试在“ TempFile”上调用“删除”时,它将很高兴地让我们在“ BankAccount”上调用“ delete”。

不好。

强模式分析

进入“强模式”,这是Dart的新型系统。 (一旦Dart 2.0到货,我们就不需要这个名称;它只是“类型系统”)。

Dart分析仪已经支持强模式静态分析了一段时间。 它使用类型推断来确定您最可能表示的类型,并要求每个变量只能具有一个类型。 它还增加了对覆盖和泛型的严格要求。

如果我们将上面的代码片段提供给启用了“强模式”的分析器,它将告诉我们:

  错误:无法将元素类型“ BankAccount”分配给列表类型“ TempFile”。 

……这似乎是合理的。 问题解决了。 还是?

不幸的是没有。 有几种方法可以欺骗静态分析。 例如,我们可以使用“ new List.from”,它使用任何“ Iterable”:

  void main(){ 
    var list = new List  .from( 
        [新的TempFile(),新的BankAccount()]); 
    cleanUp(列表); 
  } > TempFile已删除。 
  > BankAccount已删除。  哎呀! 

……分析仪无能为力。 静态检查根本无法解决此问题。

强模式正确

在这里,我们探讨稳健性的概念; 类型系统是否能够兑现其承诺。 通过分析器进行额外的静态检查有助于捕获错误,但不足以消除所有漏洞。 所需的是一些其他运行时检查。

当前,只有一个Dart运行时可实现这些检查。 Dart Dev编译器(DDC) 。 如果我们使用DDC运行最后一个代码片段,则会出现运行时错误:

  类型“ BankAccount”不是类型“ TempFile”的子类型 

因此,我们的银行帐户是安全的。 具有运行时检查功能的强模式可以确保,如果我们尝试运行“ TempFile.delete”,则在任何情况下[1]我们都永远不会运行“ BankAccount.delete”。

飞镖2.0

在这里,我们返回有关Dart 2.0及其重要意义的公告。

DDC是添加这些检查的唯一运行时的原因是,它们破坏了对语言的更改。 曾经有效的程序不再有效。 DDC是一种开发工具,因此不需要编译并运行所有有效的Dart。 VM和dart2js做。

因此,随着对Dart 2.0的更改,那些具有类型问题的程序现在可以被宣布为无效-所有运行时都可以继续提供符合其要求的类型。 对于我最喜欢的编程语言,一个圆满的结局和重要的一步。