ECMA-335(CLI)标准读书笔记（第一部：概念和架构第7章）

拓跋江

于 2022-06-20 10:50:24 发布

阅读量255

点赞数

分类专栏： protocol 文章标签：架构 linq p2p

原文链接：http://www.cnblogs.com/cubean/

版权

protocol 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

7. CLS

7.1 介绍

CLS是一套倾向于提高语言互操作性的一套规则。我们应当遵循这些规则。11章将详尽得描述和总结。CLS的一致性是为CLI实现而生的类型的一个特征。这种类型除了遵循CLS规则外还必须遵从于CLI标准。这些额外的规则只应用于集合间可见而不是集合里定义的类型，也应用于集合外可访问的成员，也就是那些有public，family(不含sealed类型)，family-or-assembly(不含sealed类型)可访问性的类型。

【注意：构成CLS兼容代码的库在这儿被作为framework使用。为CLI产生代码的编译器能够用这些库，但不能产生或扩展这些库代码。这些编译器被作为consumers使用。能产生并扩展frameworks的编译器被作为extenders使用。在每个CLS规则的描述中，额外的文本信息用于帮助读者理解规则在每种情况下的意思。】

7.2 CLS遵循性的观点

CLS是一套用于产生集合的规则。因为CLS被设计为支持库和用于编写它们的高级语言的互操作性，所以通常需要从高级源码和工具的角度考虑CLS规则，譬如用于产生集合的编译器。因为这个原因，CLS规则的描述中加了些标注信息来帮助读者理解规则在几种不同的工具和用户的类中的意义。这就是那些：framework, consumer, extender。

7.2.1 CLS framework

构成CLS兼容库的代码在这儿被作为framework使用。Frameworks被设计用于广泛的编程语言和工具，包括CLS consumer和extender语言。遵循CLS规则能使库的作者确保库能被更广泛的工具类使用。下面就是应当遵循的规则：

· 避免使用常用的名字作为编程语言中的关键字

· 不要期望framework的用户能写嵌套类型

· 假定来自不同接口的同名方法的实现是独立的

· 不要指望值类型的初始化能被自动赋予指定的初始化值

· 假设用户能够理解使用泛型和方法，但不要要求他们去定义新的泛型及方法，重载已存在的泛型及方法或者部分处理已创建的泛型。

CLS规则的标准文本见7.2章的最后部分。

7.2.2 CLS consumer

CLS consumer 是一种被设计为允许访问CLS兼容框架所有特征的语言或工具，但并不需要去产生它们。下面是CLS consumer被期望做到的一些事情：

· 支持调用任何CLS兼容的方法或委托。

· 具有一种调用名字在语言中是关键字的方法的机制。

· 支持调用独特的方法，这些方法的类型有相同的名字和签名，但是实现不同的接口。

· 创建任何一个CLS兼容类型的实例。

· 读取和修改任何CLS兼容的字段。

· 访问嵌套类型。

· 访问任何CLS兼容的属性。除了调用getter和setter属性的方法外不需要任何特殊支持。

· 访问任何CLS兼容的事件。除了调用为事件而定义的方法外不需要任何特殊支持。

· 有一种导入、实例化和使用泛型和泛型方法的机制。

【注：Consumers应该考虑支持：

· 为了匹配语言定义的规则，对泛型方法做类型推断；

· 在公共的父类型中构造语法来明晰模糊的部分】

下面列出了CLS consumer工具不需要支持的：

· 创建新类型或接口。

· 除了static literal fields，在字段和参数上初始化metadata（见第二部分）。注意，consumers能选择初始化metadata，但也能在任何除了static literal fields地方安全地无视metadata。

7.2.3 CLS extender

CLS extender是一个被设计为允许编程人员使用和扩展CLS兼容框架的语言或工具。CLS extender支持一个行为被CLS consumer支持的超集（例如一切适用于CLS consumer的也适用于CLS extender）。除了支持consumer外，还需要能够：

· 定义新的CLS兼容类型来扩展任何CLS兼容的基类，不包括sealed的。

· 具有一种调用名字在语言中是关键字的方法的机制

· 提供独立实现受类型支持的所有接口的所有方法。也就是说，对于extender而言，只要求一段单一的代码来实现具有相同名字和签名的所有接口方法是不够的。

· 实现任何CLS兼容接口

· 替换metadata上所有CLS兼容的定制属性

· 定义新的CLS兼容（非泛型）类型来扩展任何（非sealed）CLS兼容的基本类型。有效地基本类型包括正常的（非泛型）类型和完全构造的泛型。

【注：Extenders应该考虑支持：

· 为了匹配语言定义的规则对泛型方法做类型推断；

· 在公共的父类型中构造语法来明晰模糊的部分】

Extenders不需要支持下面：

· 定义新的CLS兼容接口

· 定义嵌套类型

· 定义泛型和方法

· 重载存在的虚泛型方法

CLS被设计得既足够大以富有表现力也足够小而使得所有的语言都能够很好得适应它。

CLS规则48：如果在同一类型中声明的两个或两个以上的CLS兼容方法具有同样的名字，对于类型实例的一个特定集合，它们有相同的参数和返回类型，那么那些类型实例中所有的这些方法在语义上就应该是相同的。

【注：CLS(consumer)：可能选择方法中的任何一个

CLS(entender)：同consumer一样

CLS(framework)：不应该暴露违反本规则的方法】

【注：为了避免冲突，尽管这个版本中增删了一些规则，CLS规则仍遵循了旧版本标准中的旧编号方式。所以，这部分的第一个规则就是规则48】

7.3 CLS兼容

当这些规则被详细得介绍的时候，它们以一种通用的格式被描述。例如，看下面的第一个规则。第一段指出了规则本身。然后下面就跟着从上面提到的3个不同的角度对规则的一些连带描述。

CLS定义了语言互操作规则，仅仅用于外部可见的内容。语言互操作性的CLS单元是集合——也就是说，在单个集合内部，对使用的编程技术没有限制。这样，CLS规则仅用于那些在限定集合上外部可见（见8.5.3章）并有public、family或family-or-assembly访问权限（见8.5.3.2章）的部分。

CLS规则1：CLS规则仅用于类型中限定集合外部可访问或可见的那些部分。

【注：CLS(consumer)：无影响

CLS(extender)：当编译时检查CLS兼容性时，一定要将规则应用于集合外部将要被导出的信息。

CLS(framework)：CLS规则不用于集合内部的实现。这种情况下类型仍然是CLS兼容的：所有的公共访问部分（那些对在另一个集合中代码执行有效的类、接口、方法、字段、属性和事件）由签名的CLS兼容类型组成或者对非CLS兼容做了明确标记】

任何构造都被排除在CLS之外，因为它不可能迅速地验证代码。这就允许所有的CLS兼容的语言翻译程序可以选择产生可验证的代码。

7.3.1 把项标记为CLS兼容

CLS详细说明了怎样去标记集合的外部可见部分以说明它们是否遵循CLS要求。（实现者被阻止将扩展标记作为本CLS兼容的标准。）这用定制属性机制来解决（见9.7章和第二部分）。类System.CLSCompilantAttribute(见第四部分)指出了哪些类型和类型成员是CLS兼容的。它也能被附在集合上来为所有的集合包含的顶级类型指定缺省的兼容级别。

System.CLSCompilantAttribute的构造带了一个Boolean参数指出是否该项与它所关联项是否为CLS兼容的。这允许任何项（集合、类型或类型成员）被明确地标记为CLS兼容或者不兼容。

决定CLS兼容性的规则是：

· 当集合不带有明确的System.CLSCompilantAttribute时，应该缺省带System.CLSCompilantAttribute(false)。

· 缺省的，一个类型继承其封闭类型(对嵌套类型)的CLS兼容属性或者获得依附于集合（对于顶级类型）的兼容性级别。一个类型能被标记为CLS兼容或者通过附加System.CLSCompilantAttribute属性标记为不兼容。

· 缺省的，其它成员（方法、字段、属性和事件）继承它们类型的CLS兼容性。它们也能通过附加System.CLSCompilantAttribute(false)属性来标记为不兼容。

CLS 规则2：非CLS兼容类型的成员不应当被标记为CLS兼容。

【注：CLS(consumer)：能够忽略任何使用上面规则的CLS不兼容的成员。

CLS(extender)：应该鼓励正确地标记新创建的集合和公开的导出类型和成员。大力鼓励编译时强制执行CLS规则。

CLS(framework)：应该正确地标记所有的公开的导出成员来标明其CLS兼容性。这里指定的规则可以用来减少所需的标记数目（例如，如果所有的类型和成员都是兼容的，或者仅有少数例外的需要被标记，那就标记整个集合）】