回應「遊客」意見

（因為太長了，張貼在正文看起來比較舒服。）

精闢見解！

《The Java Programming Language, 4/e》以 "contract"（契約）的概念貫串全書。作者在 p.41 如此描述：

一個常見的假設是，class 宣告的函式就是 class 的完整契約。函式語意也是契約的一部份，即使它們可能只描述於文件內。兩個函式可能擁有相同的名稱和參數，並擲出相同的異常（JK 注：即 signature 相同），但如果它們的語意不同，兩者就不等同。

因此當程式員用 interface construct 描述一個介面（一份契約）時，語意也是其中非常重要的一部份，即使那可能無法在語言內表現。JavaPL4e 在 p.125 介紹擴充（或實作）多個「帶有同名函式」的 interfaces 時，就舉了一個滿有趣（但不知道實不實際）的例子。

當然, 這樣泛用性, 就小了一點點 ..

嗯，現行 C++ GP 的模式下，"entity --- concept --- entity" 兩兩之間皆不相依（e.g. std::sort --- RandomAccessIterator --- std::vector<int>::iterator），而 OOP 的 "entity --- interface --- entity" 兩兩之間仍有相依關係（e.g. java.util.Collections.sort --- java.util.List<T> --- java.util.ArrayList<T>）。前一種模式便引發「有相同的操作介面者, 不一定皆符合特定領域的語義」的問題，因為「符合契約與否」並非由 rhs entity 自己明確宣稱（which is much easier and can be more certain），而是從 concept 那一端檢驗，但既有的語言沒辦法闡明「語意」供 concept-checking mechanism 檢驗，所以「從 concept 那一端檢驗」有麻煩。

C++0x 的 concept system 多以 STL 為例，我也用 STL 的組件為例比較清楚。目前的 concept system 提案確定會把 "algorithm --- concept" 這一段（以及 concept 本身）明確表示出來，而 "concept --- data structures (incl. iterators, containers, ...)" 這段則有兩種提案（ref. N1799 p.29 ~ 42）：一種是不指明（implicit model declarations），一種是明確宣告模塑關係（explicit model declarations，也就是讓我憂心的提議）。倘若指明了，那又和 OOP 的模式有何不同？只是從 "programming to the interface" 變成 "programming to the concept"，並從執行期變成編譯期而已。所以我在《Collected Papers of Alex Stepanov》裡面說 "compile-time object-oriented programming"。在現行 C++ GP 模式下，兩側的 entities 可以獨立發展又能無隙組合（thus "generic"）。如果最後走到 explicit model decl.，C++ concept 大概就真的變成 Java interface 的 compile-time counterpart，而減少 C++ GP 的泛用性；但若採用 implicit model decl.，又不能檢驗語意。實在是兩難哪！

不過還有一種可能 ─ 我的論證方向（i.e. 抽象化）錯誤。OOP 那邊因為讀了《Object-Oriented Analysis and Design with Applications, 2/e》所以比較清楚，而 GP 這邊的基礎相較不穩。所以我希望能「見到 generic programming 的本質」:)。

--
「遊客」真是神祕耶 XD。