C#首席設計師Anders Hejlsberg專訪（2）轉

設計 Osborn:

     讓我們進入文法細節。我在想，C#是否包括對Regex的內建支援。我沒有在語言參考裡看到它，或許它可能在別的什麼地方吧。

Hejlsberg:

     首先，在基底類別庫裡有一個Regex類。我們並沒有在語言裡加入對Regex的任何直接支援，但是，實際上我們有些非常類似的特性。並不值得對它們做重大的處理。但是，比如當你需要指定一個時候—我們給你這個能力去寫一個逐字字串而不需要你每次寫兩個後斜杠。當你寫Regex時並且當你的Regex裡的引號還套引號時，它實際上有極大的協助。雖然這個協助不足掛齒，但顯然其核心在.NET架構裡，而這個架構可以被任何程式設計語言共用。

Osborn:

     C#和Java名字空間看起來不同。它們是否概念相同而實現上不同？

Hejlsberg:

     概念上是的，但是在實現上非常不同。在Java裡，包名也是物理的東西，它指定了你的原始碼檔案的目錄結構。在C#中，物理包和邏輯名稱完全獨立，無論你如何稱呼你的名字空間，它都和你的實際代碼的物理包不相關。這就給你更多的彈性—把物理上分布的單元封裝在一起，並且不強迫你建很多的目錄。在語言自身，有很多很明顯的區別。在Java裡，包也是你的物理結構，因此，Java源檔案必須在正確的路徑裡，並且只能包含一個公開類型或者一個公開的類。因為C#沒有那種物理和邏輯上的綁定，所以你可以任意命名你的源檔案。每一個源檔案都可以被多個名字空間使用並且可以帶有多個公開類。進一步講，你可以把所有的源碼寫在一個大檔案裡，或你可以把它們分散到交叉的小檔案中去。概念上講，C#編譯時間發生了什麼—你給編譯器提供了所有構成你的工程的源檔案，然後它只管前進並指出該幹什麼。

Osborn:

     我有一個關於泛型程式設計的問題：你認為它是個重要的概念嗎？它應該成為物件導向語言的一部分嗎？如果是的話，你們把泛型程式設計加為C#的一部分的計劃如何？

Goodhew:

     好的。在第一個版本裡包括泛型程式設計的願望受到了限制。並不象每一個人以為的那樣，微軟並沒有無限制的資源。在這第一個版本裡，我們不得不做一些困難的決定。

Osborn:

     有多少人蔘與開發C#？

Hejlsberg:

     語言設計組由4個人構成，編譯器組由另外五個開發人員構成。

Petrusha:

     架構呢？

Hejlsberg:

     那就多了，整個公司都被捲入了。

Goodhew:

     就整個Visual Studio和.NET平台組而言，我們的部門大概有千人左右。包括程式管理員、開發人員、測試人員，包括所有建立常式、架構、運行時、ASP編程模型的人員以及其它所有的人比如我，管理層的。

Hejlsberg:

     就你剛才所說的泛型方面，我明確地認為它是個非常有用的概念，並且你當然可以列舉出發生在學術界和業界所有的泛型研究。模板是該問題的一個解決方案。在我們內部討論中，我們決定要在新平台裡做這個事情。但我們真正喜歡做的是讓底層的運行時理解泛型。這和如何建立泛型原型是不同的。用Java的“擦除”概念系統裡沒有真正的泛型知識。如果通用語言執行平台理解泛型的概念，多種語言就可以共用這個功能。你可以在一個地方用C#寫一個泛型類，別的人用別的語言也可以使用。

     使泛型成為運行時的一部分還可以使你更有效率的做某些事情。泛型執行個體化的最理想的時間是在運行時。如果用C++，模板的執行個體化發生在編譯時間，你有兩個選擇：聽任你的代碼膨脹或試圖在連結時去除掉一些膨脹代碼。但是，如果你有多個應用，你可能會忘記這一點，你將只能得到膨脹的代碼。

     如果把泛型的知識納入通用語言執行平台，則運行時可以理解—當一個應用或組件請求一個“Foo”列表時，它首先會問：“我已經有了一個執行個體化的“Foo”列表了嗎？”如果是，就用那一個。實際上，如果Foo是一個參考型別，並且我們設計正確的話，我們可以讓所有參考型別共用一個執行個體。對於實值型別，比如整型和浮點型，我們可以為每一個實值型別建立一個執行個體，但這應該在應用請求時才做。為了把泛型加入運行時，我們已經做了大量的設計工作和必要的基礎性工作。

     你先前提到的關於IL的東西是有意思的，因為加入泛型的決定影響了IL的設計。如果IL指令嵌入類型資訊，如果，例如，一個“加”指令不再是個“加”了，而是一個整數“加”或是浮點數“加”或是一個雙精確度數“加”，你就把類型資訊硬加入到了指令流裡，並且在這一點上來說IL不是泛型的。我們的IL格式實際上是真正的類型中立的。並且，為了保持類型中立，我們可以遲些時候加入泛型而不會給我們帶來麻煩，至少不會太麻煩。這也是我們的IL和Java的位元組碼看起來不一樣的原因之一。我們IL類型中立。“加”指令可以加棧頂的任何兩個東西。在泛型世界，當它被初始化時，它可以被翻譯成不同的代碼。

Osborn:

     所有.NET語言都可獲得泛型能力嗎？

Hejlsberg:

     是的。微軟劍橋研究院已經建立了一個支援泛型能力的通用語言執行平台和C#編譯器的版本，我們正在研究如何儘快使其前進。第一個版本是不可能加入泛型了，我們知道的就這麼多。但是我們正在工作以確保我們在第一個版本裡做了正確的事情從而使泛型可以適用於整個藍圖。

Osborn:

     C#和.NET架構以及Visual Studio的下一個版本計劃發行日期是？

Goodhew:

     唔，我們為來這兒參加PDC的6500名人員帶來了技術預覽版。我們希望2000年秋季的某個時間發布beta版，然後在準備好以後，我們發布發行版。我們所做的一個真正令人激動的事情是看看Windows2000發行版發布進行的如何，以讓關鍵客戶參與到合作開發和合作部署的進程中來。關於.NET架構和Visual Studio.NET，我們將再次和客戶一起工作以決定最終產品的發行日期。我們打算讓他們告訴我們什麼時候產品該就緒了。並且，因為有真正的客戶參與到這個進程中來，我們將獲得更好的產品品質。這種做法的不利的一面是使產品開發和發布的進程有點不確定。但這是根本性的改變。我們在尋找一個打破品質障礙的產品發行方式，而不僅僅是挑一個武斷的日期說我們要發貨了。

Osborn:

     因此，不是一個程式碼完成的日期，我們在尋找一個“準備好出發”的日期？

Goodhew:

     是的，沒錯。我認為開發人員將會發現Visual Studio.Net發行版是微軟歷史裡最高品質的發行版本之一。

Osborn:

     你們已經把C#提交給ECMA[譯註：歐洲電腦製造商協會]。標準化真的是一個嚴肅的目標嗎？你希望在其它平台上也可使用C#嗎？

Hejlsberg:

     的確如此！把C#作為一個可能的標準提供給業界當然是我們的目標，這也是我們把它提交給ECMA的原因之一。在引導這個有著公用語言基礎設施的公用設計的語言的進程中，我們當然希望得到ECMA的支援。關於公用基礎設施，我的意思是指這個規範所規定的一個核心類庫集，如果其它公司使用其它平台實現它，他們有理由期望發現可以在他們的程式裡利用這些類。

Goodhew:

     我想指出的是我們正在和ECMA做真正的開放標準。當ECMA為C#和公用語言基礎設施達成標準後，在ECMA的著作權和授權政策下，真正的開放將可實現。任何客戶、任何人都可以被授權ECMA C#標準，子集之，超集之，並且不必付版稅。他們可以在任何平台和任何裝置實現之。我們完全希望人們那麼做。這和我們的競爭者根本不同。他們徘徊在標準之外，尋找某某人去為他們私人的語言貼上印花。

John:

     我在早餐和午餐時聽說：“如果微軟沒有把COM搞到基礎設施中去，平台會多麼具有可移植性？”

Hejlsberg:

     完全可能。COM並非C#和公用語言基礎設施標準化之必須。根本不是。C#有一個完備豐富的類模型，而COM則是從另外一個視角看待應用的互通性。但是，C#和公用運行時的核心中從未說過必須要有COM、 GUID、 HRESULT、 AddRef 或 Release等等。一個都沒有。.NET 通用語言執行平台徹底摒棄了COM，但它還是給了你巨大的COM互操作能力。鑒於先前所述，我仍然認為它將非常重要，但絕非不可或缺。

Goodhew:

     我認為這些評論起因於我們公開的最初版本的語言規範。微軟在某次會議上把它寫進了規範。在那次會議上，我們認為按照微軟平台來說這是非常重要的。結果，我們在規範裡多次引用COM和DLL這樣東西。DLL是如何在已給定平台上啟用本地代碼的更多的一般性問題中的一個特例。對於納入標準化組織以及和象IBM的人（我們和他們一起制訂SOAP規範）一起工作的一個好處是我們可以不做任何這樣的提及，以防止在規範的未來版本裡，把我們自己綁死或鎖定在象COM架構這樣的東西上。

     就象Anders說的那樣，COM互操作能力和COM支援對我們和已有的微軟客戶來說是極其重要的。我認為為了在.NET支援COM我們做了大量的工作。但是，業界的人們已經閱讀了大量的我們對COM和DLL字眼引用的東西，他們由此推論.NET僅僅是為Windows平台設計的，這是完全錯誤的。

Hejlsberg:

     並且，我認為就象COM的互操作能力對於微軟和在微軟平台上構建解決方案的客戶很重要一樣，C#和公用語言基礎設施的標準化將允許在任何其它平台上選擇實現這個語言以加入意義重大的互操作能力。

Osborn:

     所以你們將不會堅持應該有個什麼“純C#”和“純.NET”的實現？

Hejlsberg:

     什麼叫“純”？真正有多少“純”Java應用存在？我冒險猜測一下，非常非常少。那就是我估計的數量。讓我們承認這一點，人們希望能利用他們已存在的代碼。不可能叫那些公司把什麼東西都扔掉。

Goodhew:

     你和Roger Sessions交流過嗎？[編註：Roger Sessions是ObjectWatch公司的CEO，並且是《COM+ and the Battle for the Middle Tier》的作者] 。

Osborn:

     沒有。

Goodhew:

     Roger談到了EJB規範的相關章節，那兒講了賣方[vendor]許可擴充。毫不奇怪，賣方擴充包括諸如交易管理、安全、訊息以及其它更多的方面，這在構建企業級系統中是相當重要的。在一篇文章[譯註：http://www.objectwatch.com/issue_24.htm]裡，Sessions粗略地列舉了11個領域的機能，這是可容許的賣方規範實現。因此，如果你選擇IBM Websphere作為你的EJB實現，你為你的EJB應用寫的代碼將不可避免地被鎖定在Websphere。Java是100%純和100%可移植的概念是不正確的。在IBM的開發人員工作網站上，有一個偉大的專訪[譯註：http://www-106.ibm.com/developerworks/features/gosling/index.html]。James Gosling直接指出了這一點。他說，是的，整個“寫一次到處運行”、“100%純的東西”真是個愚蠢的想法，更多的是屬於營銷上東西。他說，實際上，“我們並不認為我們能夠交付這一切，基本上，我們辦不到”。這就是這個語言的發明者說的，不存在什麼純粹性和可移植性。

Osborn:

     我們有沒有遺漏一些沒透露的C#的偉大的特性或創新，你願意補充一下嗎？

Hejlsberg:

關於.NET架構，隱含地，也包括C#，我想提的一點是：它是構建分布式應用的手段。並非很久以前，我們建立兩階層的客戶/服務應用，然後對象協議如CORBA、 IIOP、 RMI、和DCOM 接踵而至。這種類型的編程是EJB—（CORBA或RMI的底層實現[譯註：DCOM除外]）的基礎。我們已經會構建這種強串連式的分布式系統，但它們不具備伸縮性。它們在WEB上不能夠伸縮因為它們是有狀態的，它們在服務端保持狀態，你不能夠轉入另一台機器，把它插入並讓相關東西複製自己。

當初，當我們坐下來著手設計.NET架構時，我們回頭看了看Web上究竟發生了什麼。它正在變成鬆散串連、非常分布式的世界。我們努力理解它對潛在的編程模型的影響。因此，我們從根本上假定分布式的應用是構建在鬆散串連、無狀態風格的。依此，我們做出的設計可提供巨大的伸縮性。你只管擴充。你轉入更多的架構並且把它們插入。一旦做出了這個根本性的假設，一切就隨之改變。它改變了怎樣設計你的根本服務，怎樣設計你的訊息，甚至是怎樣設計你的使用者介面。這是一個新的編程模型。我們已經選擇了XML和SOAP作為使這個模型工作的方式。它們被深深地整合到.Net。並且這種整合對於我們在設計.NET架構時做出的每一個決策是如此核心，以至於它不是那種你只是進來蜻蜓點水地逛一逛就可以的東西。

Osborn:

     你能指出一些對程式員來說明顯特別的地方嗎？

Hejlsberg:

     一個相當好的例子是XML是如何被整合到C#中的。C#中有特性[譯註：即attribute，關於名詞譯法的說明，上文有描述]的概念，它允許你向類型和成員加入宣稱性資訊。就象你可以說某個成員是公有的或私人的一樣，你可能還想說這個是事務的，或者這個假定是個Web service，或這個假定被以XML方式的序列化支援。因此，我們加入特性以提供一般性機制，但是我們在所有的Web service和XML基礎設施中都用到了它。我們還給你用特性修飾類和欄位的能力。在你的類中，你可以說“當這個類型變成XML時，它應該變成“this”標籤名，並且屬於“this”XML名字空間。”你將有能力指定一個欄位變成一個元素，而另外一個變成屬性[譯註：此處指XML中的屬性]。你還能夠控制XML的模式[譯註：即schema]；在你的類聲明的地方控制它，這樣，所有附加的宣稱性資訊就都可以獲得了。一旦以該方式正確地使用特性修飾你的C#代碼，系統就可以簡單把它轉化成XML中一個指定的類，線上上傳輸，當它傳回時，就可以在另一端重建該對象。這都是在一處定義完成的。它不象傳統的定義檔案或多種資訊和命名模式。它就在那兒。當你在IDE中建立它們時，它就給了你完整的聲明。我們還可以提供進階工具，讓它幫你做這個事。

     我知道我有點離題了，但是我們提供的這些基礎設施的確令人興奮。單單因為我們有這些特性，你就可以請求XML序列化基礎設施或Web service基礎設施把已給出的類翻譯成XML。當你這麼做了，我們實際上將為這個類配上XSD模式，並且我們將建立一個特別的解析器，它是從我們一般的XML解析器派生出來的（.NET基類的一部分），並且重載方法並加入邏輯，因此它是專門為那個模式服務的。所以，我們已經初始化好一個解析器，可以本地代碼的速度解析XML。如果它不正確，我們將給你一個體面的出錯資訊，它可以精確地告訴你是什麼出了問題。我們可以在代碼緩衝基礎設施中緩衝它，它將坐等直到下一次一個具有同樣模式的類來臨並將發生作用，“嘭！”，我的意思是，難以置信，難以置信的生產能力！

Osborn:

     所以，在蓋子下的確有很多有趣的引擎。

Hejlsberg:

     是的，並且我認為，當在這個領域裡達到這個思想時，我們是領先的一代。

Osborn:

     精彩之至。謝謝，耽誤你時間了。

Hejlsberg:

     不客氣。