超级会员免费看
重新审视参数类型和虚拟类
1. 类型细化在不同语言中的应用
类型细化在不同编程语言中的表现和应用各有特点。以SCALA和gbeta为例，它们在类型细化的使用上既有相似之处，又存在明显差异。
在SCALA中，我们先来看传统的
zip
方法实现，代码如下：
abstract class Pair[Fst, Snd] {
val fst: Fst
val snd: Snd
}
class List[A] {
def zip[B](y1: List[B]): List[Pair[A,B]] = {
val res = new List[Pair[A,B]]()
...
}
}
object Main extends Application {
val myl1 = new List[Int]
val myl2 = new List[String]
val pairs = myl1.zip(myl2)
}
然而，SCALA语言规范指出，所有值约束仅用于结构比较，不能用于类型约束，这就导致类型细化只能表达对类型成员的约束，无法实现一些特定的类型约束测试。例如，SCALA的类型细化虽然能定义类型约束，但由于其主要运行平台是Java虚拟机，字节码语言不支持类型参数信息，所有类型参数在编译时会被擦除，所以无法在运行时进行类型测试。
而在gbeta中，类型细化不仅可以像图2那样静态使用，还能用于动态类型测试结构。比如，通过类型细化可以判断
Graph
类的两个实例是否具有相同的包对象，这类似于
instanceof
测试，是gbeta中类型细化的新特性。以下是gbeta中相关代码示例：
{
Pair: %{
Fst:<object; Snd:<object; fst: ˆFst; snd: ˆSnd;
};
List: %{
elm:<object;
zip: %(| res:ˆList[ elm=ElmPair] ) {
b:< @List;
ElmPair: Pair%{ Fst:: elm; Snd:: b.elm};
#
new List %{ elm::ElmPair }ˆ | res;
...
};
// (1)...
};
myl1:@List %{ elm:: int };
myl2:@List %{ elm:: string};
r: ˆList[Pair[Fst=int,Snd=string]];
#
myl1.zip%{ b:: @myl2 } | r;
// (2)...
}
2. 重新实现
zip
方法
为了进一步探讨类型参数化类在不同场景下的适用性，我们重新实现了
zip
方法。首先是在SCALA中使用类型成员和类型细化的实现：
abstract class Pair {
type Fst; type Snd; var fst: Fst; var snd: Snd
}
abstract class List {
type elm >: Null
var current: elm = null // Dummy one element list
abstract class Zipper {
val b: List
type ElmPair = Pair{ type Fst = List.this.elm;
type Snd = b.elm; }
def zip(): List{ type elm = ElmPair } = {
val res = new List{ type elm = ElmPair }
...
res
}
}
// (1)...
}
object Main extends Application {
val myl1 = new List{ type elm = Integer }
val myl2 = new List{ type elm = String }
val zipr = new myl1.Zipper{ val b = myl2 }
val out: List{ type elm =
Pair{ type Fst=Integer; type Snd=String }} = zipr.zip()
// (2)...
}
这个实现相对复杂一些。在第10行附近，我们创建了类型约束
Snd = b.elm
，由于该约束用于
zip
方法的返回类型，所以不能在参数列表中声明
b
。为此，我们在包含
zip
方法的包装类
Zipper
中创建了一个抽象值
b
，以便在类型成员
ElmPair
中引用
b.elm
。
接着是在gbeta中使用虚拟类和类型细化的实现：
{
Pair: %{
Fst:<object; Snd:<object; fst: ˆFst; snd: ˆSnd;
};
List: %{
elm:<object;
zip: %(| res:ˆList[ elm=ElmPair] ) {
b:< @List;
ElmPair: Pair%{ Fst:: elm; Snd:: b.elm};
#
new List %{ elm::ElmPair }ˆ | res;
...
};
// (1)...
};
myl1:@List %{ elm:: int };
myl2:@List %{ elm:: string};
r: ˆList[Pair[Fst=int,Snd=string]];
#
myl1.zip%{ b:: @myl2 } | r;
// (2)...
}
与SCALA版本相比，gbeta的实现更简单、更简洁。这是因为gbeta的类型细化工作方式略有不同，并且类和方法是统一的，使得方法激活成为真实对象，从而无需像SCALA示例中的
Zipper
类。
3. 列表元素迭代
在处理列表元素迭代时，不同语言有不同的选择。BETA和gbeta（类似于Smalltalk）传统上使用内部迭代，即数据结构上的迭代方法接受一段代码，对每个元素执行该代码。而C++和Java则使用外部迭代，通过显式的控制结构和迭代器对象遍历数据结构。
以下是gbeta中内部迭代的示例：
(1)
scan:%{ current:ˆelm # ... }; // call inner for each element
(2)
(myl1.zip%{ b:: @myl2 }).scan{ // called at inner
current.fst@ + current.snd.size | current.fst@
}
在这个示例中，我们无需声明当前元素或其类型，因为它从“超方法”
scan
继承而来。
而在SCALA中，自然的选择是使用迭代器，但为了探索与gbeta相同的内部迭代方式，我们实现了如下代码：
(1)
def scan(body: elm => Unit) = ... // call body on each element
(2)
zipr.zip().scan( (current:
Pair{ type Fst=Integer; type Snd=String }) => {
current.fst =
new Integer(current.fst.intValue() +
current.snd.length());
()
}
)
与gbeta版本相比，SCALA需要创建一个额外的匿名函数，并指定当前元素的类型。
4. 集合与子类型化
集合类是参数类型的主要应用场景之一，但在使用虚拟类时，集合层次结构的灵活性可能会受到影响。例如，Bruce、Odersky和Wadler展示的类
Collection
及其子类
List
，通过创建
List
的子类
StringList
和
Collection
的子类
StringCollection
，由于设计原因，
StringList
不是
StringCollection
的子类，降低了其可重用性。
为了解决这个问题，我们提出了两种不同的方案：
-
方案一：使用虚拟类
{
Collection:%{ elm:<object; ... };
List:Collection%{ ... };
StringCollection:Collection%{ elm:: string; ... };
StringList:StringCollection & List;
takeStringCollection:%(c: ˆStringCollection) { ... };
l: @List; sc: @StringCollection; sl:@StringList;
#
//lˆ | takeStringCollection; // Compile-time error
scˆ | takeStringCollection;
slˆ | takeStringCollection;
}
在这个方案中，虽然一开始看起来
StringList
不是
StringCollection
的子类，但由于gbeta中的类型是混合集，确保了
StringList
是
StringCollection
的子类。不过，该设计并非最优，因为每次需要字符串类型的集合时都必须使用
StringCollection
，新的绑定元素类型为字符串的类会导致集合不兼容。
-
方案二：使用虚拟类和类型细化
{
Collection:%{ elm:<object; ... };
List:Collection%{ ... };
takeColOfString:%(c:ˆCollection[elm<=string]) {...};
l: @List; sc1: @Collection%{ elm::string };
sc2: @Collection%{elm:: string }; sl: ˆList%{elm:: string};
#
//lˆ | takeColOfString; // Compile-time error
sc1ˆ | takeColOfString;
sc2ˆ | takeColOfString;
new slˆ | takeColOfString;
}
这个方案更简单、更通用。通过对
takeColOfString
方法的参数类型进行类型细化，创建了一个约束，使得参数必须是
Collection
的子类，且其元素类型必须是字符串或字符串的子类。这样，不同的实例只要绑定元素类型为字符串，都能被
takeColOfString
方法接受。
综上所述，虽然虚拟类仅通过子类型关联，但在虚拟类的基础上添加类型细化，能提供一种有用的组合，使程序更紧凑，同时保持与参数类型相同的表达能力和通用性。
5. 虚拟类的优势
虚拟类在指定相互递归的类族和保留派生族（“子族”）中的子类型关系方面表现出色。以一个简单的“中国盒子”示例来说明，它是一个能够自我包装的盒子。
首先是在SCALA中使用参数类型和F边界的实现：
abstract class Box[X] {
var x: X
def getX(): X = x
def setX(x:X): Unit = this.x = x
}
abstract class ChineseBox[X <: ChineseBox[X]]
extends Box[X] {
def selfwrap() = setX(this.asInstanceOf[X])
}
class ChineseBoxFix extends ChineseBox[ChineseBoxFix] {
var x = new ChineseBoxFix
}
object Main extends Application {
val x = new ChineseBoxFix
x.selfwrap()
}
在这个实现中，
ChineseBox
类的
selfwrap
方法需要显式的动态类型转换，因为
this
的类型不是
X
的子类型。这是为了保证类型安全性，但增加了代码的复杂性。
然后是在gbeta中使用虚拟类的实现（此处假设图13的代码）：
// 假设图13的代码
// 这里可以详细描述代码的关键部分
在gbeta的实现中，通过使用第一类包建立确定的类型，避免了SCALA实现中的类型问题，无需进行类型转换，代码更加简洁和直观。
总的来说，虚拟类在某些场景下具有独特的优势，能够更自然地处理类型之间的关系，减少类型转换的需求，提高代码的可读性和可维护性。
6. 相关工作
自Bruce、Odersky和Wadler对参数类型和虚拟类型处理不同设计问题进行比较以来，围绕虚拟类型和虚拟类开展了大量工作。相关语言如gbeta、SCALA、CaesarJ和Object Teams等都在不断发展和完善。近年来，类型参数还出现了高阶的发展趋势，一个带有参数的类型参数本质上对应于一个包含虚拟类的虚拟类，但详细探讨这个话题超出了本文的范围。
在未来的编程实践中，我们可以根据具体的需求和场景，灵活选择参数类型和虚拟类，充分发挥它们的优势，以实现更高效、更可靠的代码。同时，随着编程语言的不断发展，我们也期待更多创新的类型系统和编程模式的出现。
重新审视参数类型和虚拟类
7. 不同实现方式对比总结
为了更清晰地展示不同语言和实现方式在各个方面的差异，我们制作了以下表格：
| 对比项 | SCALA（参数类型） | SCALA（类型成员和细化） | gbeta（虚拟类和细化） |
| — | — | — | — |
|
zip
方法复杂度 | 较简单传统实现 | 较复杂，需额外包装类 | 简单简洁，无需额外类 |
| 类型约束测试 | 编译时约束，运行时无法测试 | 编译时约束，运行时无法测试 | 可静态和动态测试 |
| 列表迭代 | 需额外匿名函数和指定类型 | 需额外匿名函数和指定类型 | 无需声明元素类型 |
| 集合子类型化 | - | - | 可解决部分子类型问题，方案二更优 |
| 中国盒子示例 | 需动态类型转换 | - | 无需类型转换 |
从这个表格可以看出，不同的实现方式各有优劣。SCALA在参数类型和类型成员细化方面，虽然有一定的类型表达能力，但在运行时类型测试和代码简洁性上存在不足。而gbeta的虚拟类和类型细化在很多场景下能提供更简洁、更灵活的解决方案。
8. 类型系统对编程的影响
类型系统在编程中起着至关重要的作用，它直接影响着代码的安全性、可维护性和灵活性。
- 安全性 ：一个强大的类型系统可以在编译时捕获很多潜在的错误，减少运行时的异常。例如，在SCALA的参数类型和F边界实现中，虽然需要进行动态类型转换，但这是为了保证类型安全。而gbeta的虚拟类实现通过更紧密的类型关联，避免了类型转换，同样保证了类型安全。
-
可维护性
：代码的可维护性与类型系统的设计密切相关。如果类型系统过于复杂，会增加代码的理解和维护难度。如SCALA中使用类型成员和细化实现
zip方法时，由于复杂的类型约束和额外的包装类，使得代码的可维护性降低。而gbeta的简洁实现则更易于理解和维护。 - 灵活性 ：类型系统的灵活性决定了代码在不同场景下的适应性。在集合子类型化问题中，gbeta通过虚拟类和类型细化提供了更灵活的解决方案，能够处理不同类型的集合实例，而传统的虚拟类设计则会降低集合层次结构的灵活性。
9. 未来编程趋势展望
随着编程领域的不断发展，类型系统也在不断演进。未来可能会出现以下趋势：
-
融合多种类型机制
：不同的类型机制各有优势，未来的编程语言可能会融合参数类型、虚拟类、类型细化等多种机制，以提供更强大、更灵活的类型系统。例如，结合参数类型的通用性和虚拟类在处理递归类型关系上的优势。
-
更智能的类型推导
：减少开发者手动指定类型的工作量，让编译器能够更智能地推导类型。这将提高开发效率，降低代码的复杂度。
-
支持高阶类型和依赖类型
：高阶类型可以让类型系统更加灵活，能够处理更复杂的类型关系。依赖类型则可以根据值的不同来确定类型，进一步增强类型系统的表达能力。
下面是一个简单的mermaid流程图，展示了在选择类型实现方式时的考虑因素：
graph LR
A[需求场景] --> B{是否需要运行时类型测试}
B -->|是| C[考虑gbeta虚拟类和细化]
B -->|否| D{对代码复杂度要求}
D -->|低| E[考虑SCALA参数类型]
D -->|高| F{是否处理集合子类型}
F -->|是| G[考虑gbeta虚拟类和细化方案二]
F -->|否| H[综合评估选择]
10. 实际应用建议
在实际编程中，我们可以根据具体的项目需求和场景来选择合适的类型实现方式：
1.
简单数据处理
：如果项目主要是进行简单的数据处理，对类型系统的要求不高，SCALA的参数类型可能是一个不错的选择。它的语法简单，易于理解和使用。
2.
复杂类型关系和递归结构
：当项目中存在复杂的类型关系和递归结构时，如相互递归的类族，gbeta的虚拟类和类型细化能够提供更自然、更简洁的解决方案。
3.
集合操作和子类型化
：在处理集合操作和子类型化问题时，gbeta的虚拟类和类型细化方案二可以提高集合的灵活性和可重用性。
4.
运行时类型测试需求
：如果项目需要在运行时进行类型测试，那么gbeta的类型细化特性将是必不可少的。
总之，选择合适的类型实现方式需要综合考虑项目的各种因素，权衡不同方案的优缺点，以达到最佳的编程效果。
扫一扫
1802
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
