Programming Languages PartC Week3学习笔记——子类型(Subtyping)的讨论
@
Subtyping From the Beginning

需要一种包含可修改fields的records,并且具有type system,支持subtyping的语言。我们学过的多种语言都不符合这种要求,因此需要我们自定义一种语法(假定一种语言语法)。




根据上述语法规则,下面的程序(类似子类应用在父类的场合)不会通过类型检测,因为type system此时会认为c不符合p的类型。这是不合理的,因为我们调用distToOrigin时不会用到color这个额外的field。

尽管我们不希望拥有错误field的类型变量被调用(应该在type checking时阻止),但也不应该阻止额外的field。
subtyping是实现这种想法的优雅手段。

The Subtype Relation
为了解决上一节的问题,我们需要在我们的语法规则中增加两条新的规则,一是subtyping的语法,二是新的类型检测规则。(但蓝字部分是唯一需要添加到类型规则中的部分)

subtype不是一种Option

subtype需要遵守的四个规则:
- 宽度:超类型拥有具备相同类型的子类型fields的子集
- 可排列性:超类型拥有的field子集元素可以是不同顺序
- 传递性:子类型可传递
- 自反性:任何type都是自己的子类

Depth Subtyping

sphere显然不是circleY要求的参数的子类型,除非去掉其中的r,或者去掉center。但这不是我们想要的方式。很自然的想法是,我们可以添加新的规则,当record中某个field是子类型时(所有fields值都必须是子类型(注意子类型的自反性)),这个record也是子类型。这种方式叫做深度subtyping,有点类似C++的深拷贝的思想。

但这种做法不值得我们去实现,因为它打破了稳定性soundness。


如果field不能修改,那么depth subtyping就是稳定的。

Optional: Java/C# Arrays
Java或者C#中,如果t1是t2的子类型,那么t1的数组也是t2的数组的子类型。这与上一节的depth subtyping类似,也会造成问题。

为什么允许这样的操作


null可以为一些不存在的对象或方法兜底,就像ML中的Option(其中的None)

Function Subtyping
对于函数本身,如果具有subtyping的特性

例子:

新的规则,如果函数返回值是子类型,函数是子类型

但如果函数参数是子类型,函数本身不应该是子类型,否则不稳定。这里值得注意的是,因为子类型会比超类型多出来一些field,所以才会导致函数子类型不稳定。

假如参数本身是超类型(少一些field),那么函数反而可以构成稳定的子类型

上述稳定的规则可以同时使用


这一节最后强调contravariant in argument的时候老师好可爱O(∩_∩)O哈哈~
Subtyping for OOP



类和类型的区别:



Generics Versus Subtyping
泛型与子类型
泛型擅长的:


子类型不擅长作为类型”容器“,向下转型是个问题:

子类型擅长的:

对于没有子类型的语言,向函数传递不同的getter和一个泛型来实现子类型的功能

Bounded Polymorphism
混合多态,将泛型和子类型混合使用

例子:





***Summarizing All We Have Learned
总结全部课程内容
首先是课程目标:

我们学到的内容:

几种语言的对比:

要点总结:
其一 是不可修改的好处:

其他要点:


学以致用:

最后就是本课程的saying goodbye环节。整个课程学下来收货还是很多的,函数式编程确实开阔了眼见,也学到了很多程序语言设计和编程哲学,很感谢Dan Grossman老师。


浙公网安备 33010602011771号