重新学.Net[五]――CLR的多语言支持

众所周知，CLR支持多种语言，包括C#，VB.Net等等二十多种（其实说确切一点，应该是各种语言都可以提供编译器，从而运行在CLR上）。为了支持多种语言，CLR必须建立一种模式，使得各种语言都能很容易的运行在其上。而如今各种面向对象的语言，虽然在语法上各有不同，但其核心语义都是类似的。因此CLR利用了这一点，它的所有内容都是围绕着类型展开的。CLR的通用类型系统CTS，就是用来描述类型定义和行为的。
 简单的说，首先CTS定义了一些类型，分成值类型和引用类型两种。值类型包括int32，Boolean，Structure等等，运行时在运行栈上分配。引用类型包括Class，Interface，Array等等，在托管堆中分配（相信学过OO的人对这都不会很陌生）。每种类型可能会有一些成员（0到N个），包括字段，方法，属性和事件。同时每种类型都用一些访问控制权限，比如Public，Private，等等。此外，CTS中还规定了一些规则，比如：所有类型必须继承自Object，支持单继承等等。所有的这些类型设定和规则构成了CTS，一门语言编译过来，只要满足CTS要求，CLR都可以运行。因此一门语言要想运行在CLR之上，就必须服从CTS的规定和限制（比如C++需要编译运行在CLR上，就需要改变其多继承的方式）。
同时，CTS是如此的庞大，目前还没有语言可以支持它的所有特点（包括C#和VB），并且CLR也没有这个要求。这样就会带来一个问题。一种语言编写的库，如何能被其他语言调用？假设一门语言支持UInt64，用它实现了一个库，有一个方法为public int64 getInt()。这时候另外一门语言在程序设计中想调用这个库的这个方法，但是它不支持UInt64，使其根本无法使用这个库。这与CLR的多语言支持理念显然不符。
所以为了实现多语言的互通，还需要一个通用语言规范CLS，它是CTS的一个子集。所有运行在CLR上的语言，必须完全支持CLS。比如CLS中有Int16，但没有要求UInt64（CTS中都有支持），一门语言想运行在CLR之上，它必须支持Int16，但不必须支持UInt64。这也告诉我们，如果你想让你的设计的类库，框架等被所有支持CLR的语言调用，必须只能以CLS的规范公开接口，当然在内部你可以使用所有CTS支持的类型进行编程。
说直白一些，CTS是天，它包容一切，CLS是地，必须站立在它上面。大部分语言都是在两者之间（是CLS的超集，是CTS的子集），可以说是顶天立地了（不好意思，比喻有点烂，胃部不适者请自备垃圾袋^_^）。
每每考虑这个问题的时候我都会有一个疑惑。就是C#和VB.Net一定要搞得很双胞胎一样吗（两者语法习惯虽不同，但支持的特征和特点简直像到了死）？当然，微软有它的商业考虑，但我还是很怀念那个简单的VB时代，总觉得VB.Net语法就应该简单一些，好入门一些，开发效率更高一些。据说VB.Net和C#的特征集在以后要开始有所分离了，恩，希望这是真的。