GP技術的展望.docVIP

GP技术的展望——道生一，一生二 by 莫华枫 长期以来，我们始终把GP（泛型编程）作为一种辅助技术，用于简化代码结构、提高开发效率。从某种程度上来讲，这种观念是对的。因为迄今为止，GP技术还只是一种编译期技术。只能在编译期发挥作用，一旦软件完成编译，成为可执行代码，便失去了利用GP的机会。对于现在的多数应用而言，运行时的多态能力显得尤为重要。而现有的GP无法在这个层面发挥作用，以至于我这个“GP迷”也不得不灰溜溜地声称“用OOP构建系统，用GP优化代码”。 然而，不久前，在Top Language group上的一次讨论，促使我们注意到runtime GP这个概念。从中，我们看到了希望——使GP runtime化的希望——使得GP有望在运行时发挥其巨大的威力，进一步为软件的设计与开发带来更高的效率和更灵活的结构。 ??? 在这个新的系列文章中，我试图运用runtime GP实现一些简单，但典型的案例，来检测runtime GP的能力和限制，同时也可以进一步探讨和展示这种技术的特性。 运行时多态 ??? 现在的应用侧重于交互式的运作形式，要求软件在用户输入下作出响应。为了在这种情况下，软件的整体结构的优化，大量使用组件技术，使得软件成为“可组装” 的系统。而接口-实现分离的结构形式很好地实现了这个目标。多态在此中起到了关键性的作用。其中，以OOP为代表的“动多态”（也称为 “subtyping多态”），构建起在运行时可调控的可组装系统。GP作为“静多态”，运用泛化的类型体系，大大简化这种系统的构建，消除重复劳动。另外还有一种鲜为人知的多态形式，被《C++ Template》的作者David Vandevoorde和Nicolai M. Josuttis称为runtime unbound多态。而原来的“动多态”，即OOP多态，被细化为runtime bound多态；“静多态”，也就是模板，则被称为static unbound多态。??? 不过这种称谓容易引起误解，主要就是unbound这个词上。在这里unbound和bound是指在编写代码时，一个symbol是否同一个具体的类型 bound。从这点来看，由于GP代码在编写之时，面向的是泛型，不是具体的类型，那么GP是unbound的。因为现有的GP是编译期的技术，所以是 static的。OOP的动多态则必须针对一个具体的类型编写代码，所以是bound的。但因为动多态可以在运行时确定真正的类型，所以是runtime 的。至于runtime unbound，以往只出现在动态语言中，比如SmallTalk、Python、Ruby，一种形象地称谓是“duck-typing”多态。关于多态的更完整的分类和介绍可以看 HYPERLINK /wiki/Parametric_polymorphism 这里。 ??? 通过动态语言机制实现的runtime unbound，存在的性能和类型安全问题。但当我们将GP中的concept技术推广到runtime时会发现，rungime unbound可以拥有同OOP动多态相当的效率和类型安全性，但却具有更大的灵活性和更丰富的特性。关于这方面，我已经写过一篇 HYPERLINK /longshanks/archive/2007/12/06/1921273.aspx 文章 ，大致描述了一种实现runtime concept的途径（本文的附录里，我也给出了这种runtime concept实现的改进）。 Runtime Concept ??? Runtime concept的实现并不会很复杂，基本上可以沿用OOP中的“虚表”技术，并且可以更加简单。真正复杂的部分是如何在语言层面表达出这种runtime GP，而不对已有的static GP和其他语言特性造成干扰。在这里，我首先建立一个基本的方案，然后通过一些案例对其进行检验，在发现问题后再做调整。 ??? 考虑到runtime concept本身也是concept，那么沿用static concept的定义形式是不会有问题的： concept myconcept { T copy(T lhs, T const rhs); void T::fun(); ... } ??? 具体的concept定义和使用规则，可以参考C++0x的 HYPERLINK /jtc1/sc22/wg21/docs/papers/2007/n2421.pdf concept提案或 HYPERLINK /jtc1/sc22/wg21/docs/papers/2007/n2399.pdf 这篇文章 ，以及 HYPERLINK /%7Ebs/oopsla06.pdf 这篇文章 。 ??? 另一方面，我们可以通过concep