这些言语是Amingoo先生留下的非常珍贵的评价，对我也是一个学习的提升。为了让更多的人看到这个评论，特意将它作为《苛评VCL》系列文章的最后一篇发出，和大家一起分享。希望Amingoo不要见怪。

以下言语都来自Amingoo先生：

1. 这个问题不是所谓的类型问题，也不应该是在DLL内去解决的问题。如同BuilderChen所说，不认当把一个特定的OOP实现框架暴露在DLL的接口层，这样会使得这个DLL失去了共用代码的性质。

2. BPL通过DLL导出函数的方式使得不同的模块间可以使用同一个RTL。从本质上来说，它就是一种失去了通用性质的DLL。如同第一条所述的，它们的应用场合、背景和功能都有了差异。不能苛求说：要公用代码，还要公用OOP框架。这一点，Borland做不到，M$也做不到，因为没有哪两个OOP框架的实现方案是一样的。

3. “没有哪两个OOP框架的实现方案是一样的”的原因，基本上可以归结为共用代码的级别是在语言层，而非二进制代码层。所以COM宣称它的代码共用是在二进制代码层，就得到了更多的支持。同样，你也会发现COM的代码互用产生了比DLL更多的价值。——Windows的应用层基本上都构架在COM之上。

4. 二进制代码层的共用仍是有限的，因为它仍然受到硬件系统和编译系统的约束。所以COM的支持有几家，但也不是说就大一统了。更进一步的共用是在描述层，也就是说：与具体的语言和编译环境无关层面的共用。这表现在两个方面，一是接口，二是XML。接口是对代码功能的约束，XML是对代码交互的约束。你会看到，更多的厂商支持XML和接口（我这里不是指COM接口），就是因为大家都看到了这样做的价值：足够的抽象，以及没有强制性的实现要求。

5. 绕了一个圈子，我想说的是，楼主用一种纯为技术实现和使用的方式来考虑和评估架构的设计，用现在的环境下的需求来评估十年前的架构的设计。前者会使看问题不够深入，后者会有失公允。同样的一个“共用代码”和“OOP体系设计”的问题，在当前的理论研究和技术实现下的确可以有更佳的方案，但这并不是旧的架构的弊误或疏漏，而是新的应用环境产生的需求。

6. 楼主所谈论到的一些（我是说包括其它的几篇文章中的）问题，的确是DELPHI自身的局限，但大多数算不上问题。尤其是在DELPHI所适用的应用环境中，更是算不上问题。DELPHI的OOP、VCL以及COM实现方面的架构，能被广泛地使用上十年八年，不是没有它的道理的。而我们自身的架构设计能力，能保证一套系统（哪怕仅是一个OA）或者一个架构（哪怕仅是一个插件机制）能有效地使用上一年两年的，又有几个呢？因此我们大多数时候如同以管窥豹，所见者，斑斑点点而已。

7. 楼主现在的评论，有点为苛评而苛评的意思了。