《从LRS项目重构来看“数据类型”——（第二话）局部类型推理（二）》

接上一篇博客：《从LRS项目重构来看“数据类型”——（第二话）类型推理（一）》

尝试1、在过程级别中：（先定义一个没有具体类型的变量，后赋值初始化） 效果图如下：

此时，编译器没有给出我们想要的预期结果（应该显示的是Dim UNKnowType as Integer),
尝试2、（在模块级别，非局部级别来定义变量）
情况2.1（定义一个没有指定类型的变量并同时为她进行初始化赋值）

情况2.2（定义一个没有指定类型的变量，然后再赋值初始化）

以上的试验数据已经充分验证了类型推理的定义，咱们再回过头去看看类型推理的定义吧。有两个要点：
第一：类型推理只能发生在过程级别中。
第二：类型推理通过对表达式的初始化来推断变量的数据类型，如果是函数那么通过返回值来确定。如果直接是用一个值（如：字符串，或者数字……）给变量赋值，那么得到的是这个值的数据类型。
说到这里，我又突然想起了泛型和C++里面的模板（详情请点此链接http://blog.csdn.net/t131452n/article/details/45461633）
其实模板也好，泛型过程也好，都用到了这个类型推理的技术。通过上下文（函数的返回值、变量的初值）、初始化表达式（在.net机制中实现通过它进行JIT编译时，JIT编译器用指定的类型实参来替换泛型IL代码元数据中的T，进行泛型类型的实例化。这会像JIT编译器提供类型特定的IL元数据定义，就好像从未涉及到泛型一样。JIT编译器可以确保参数正确性，实施类型安全检查，甚至执行类型特定的IntelliSense（智能感知））
但是，还有一个问题，没有解决。细心的同学可能注意到了。在我们做的试验中（其中：先定义，后赋值初始化种情况，其实系统已经将变量UnKnownType指定了一个类型object（记住，这也是一个数据类型，而且是vb.net中的默认数据类型，但是此时启用的是后期绑定，因此执行的效率要相比通过类型推理做出前期绑定的代码而言要低的多）

小结：尽管后期绑定和前期绑定都能够正常运行代码，但是后期绑定形式效率低，安全性不如前期绑定。类型推理能够帮助我们在过程级别中通过初始化表达式，推断出为定义的变量的具体数据类型，并为其提供早期绑定代码并且能够做到智能感知(IntelliSense)。在vb.net中类型推理和智能感知功能的实现是有赖于vb.net机制中的Runtime,借助IL和JIT来共同实现的。
总结：学习任何东西其实都不难，只要你有想法然后动手去试一试，总会出来的。回过头去看了看自己的这个系列博客《从LRS项目来看……》,前后写了泛型、数据类型映射、数据类型推理。（后续还将继续更新）想想也没有什么难的。从和浩杰的一个小讨论，引发了自己的一连串思考，自己在这个过程中了解了大量的底层的东西，相关的知识基本上都查过了。
也许，学习的进度慢下来了一点，但是我觉得这个过程是非常快乐的！因为，这个过程中，我是积极主动的去获取知识，而不再是填鸭式的，给什么就吃什么。
接下来，我还需要继续加油和提高的地方是，自己的主线（培养计划上的学习进度问题）和这些拓展的矛盾的处理，也就是进度和相关拓展的度的把握。给自己的每个任务留2-3天的时间来查阅当时疑惑和需要拓展的东西，学会将当时不能及时迅速解决的问题进行冷处理（先挂起来，日历上定一个计划专门来解决这个问题。）