2006/08/15

回應「遊客」意見

(因為太長了,張貼在正文看起來比較舒服。)

精闢見解!

《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。

Anonymous 遊客8/16/2006 3:26 am 說:

讚, 你作學問真的很踏實!!

那就是我想的說, 沒想到書中都有寫了 ><
有沒有其他解法, 自己也不懂, 且覺得
再思考下去, 好像有點不切實際.

像 Haskell 的作法應是 explicit model
它用 declare (Eq a where ..) 來讓資料
跟某個 type class 產生關聯, 並賦予行為
但他的模型較特別, 資料與行為天生是分離的

不過就如你所說, 這樣跟 OOP 有什麼差別?
也因此, 雖然 Java 它們的「泛型」綁介面
讓很多人說, 泛型也不泛型了! 後來我覺得
其實這很重要嗎? 這只是純粹不純粹的問題!
除非你選擇 implicit model

(好啦, 還有一個問題: 一個 construct 的概念被 overloading 了. 是福是禍, 端看語言設計者的選擇. Ruby 說 multi-way; Python 說 one-way 各有各的想法)


不過話說回來, metaprogramming 這東西
C++ 要跟 Ruby 比真是相形見拙; 但我還是
滿喜歡 C++ 的, 畢竟最熟悉 XD

(只是 C++ 的發展已非我所能想像 ...)

 
Blogger Josh Ko8/16/2006 4:53 am 說:

天啊,你簡直說到我心坎裡!:D 例如

> 覺得再思考下去, 好像有點不切實際

這句 :P。發完文後我又想了想,採用 implicit model 所獲得的泛用性是否必要,還是得以實際使用模式為依歸,不是這樣單純抽象論述一番就可以解決,而「實務經驗」正是我所欠缺的。像 Grady Booch 在學理和實務都有深厚素養和經驗,他的論述才這麼具說服力(at least to me)。

> metaprogramming 這東西
> C++ 要跟 Ruby 比真是相形見拙

沒錯,Ruby 那靈活程度真是嚇死人 :P。我最感到震撼的就是 Singleton pattern 的實現手法:一行 require 'singleton' 再一行 include Singleton 就完了,乾淨又優雅!

> 但我還是滿喜歡 C++ 的, 畢竟最熟悉 XD

天啊,又說到我心坎裡!:D

以後歡迎多多討論 :)。

 

<< 回到主頁