John Osborn 著
7月，O’Reilly編輯John Osborn參加了微軟職業(yè)開發(fā)者會議。在此，他對著名的工程師、微軟.Net框架C#語言首席架構(gòu)師Anders Hejlsberg進行了采訪。Anders Hejlsberg因設(shè)計PCs上最早的語言之一—Turbo Pascal而廣為人知。他把Turbo Pascal許可給Borland公司，后又率隊創(chuàng)建了Delphi—一個極為成功的可視化的client/server應(yīng)用設(shè)計工具。訪問時在座的還有微軟C#產(chǎn)品經(jīng)理Tony Goodhew和O‘Reilly的Windows編輯Ron Petrusha。
Osborn:
我已經(jīng)看到一些關(guān)于C#（發(fā)音為"See sharp"）的新聞故事，并注意到有很多似乎傾向于這樣的觀點，或理論上說，C#不是Java的克隆就是Java的微軟替代品。如果你來做宣傳的話，你希望人們怎么評論這門語言？
Hejlsberg:
首先，C#不是Java的克隆。在設(shè)計C#期間，我們考察了很多種語言，我們考察了C++，我們考察了Java，我們考察了Modula 2、C，我們還考察了Smalltalk。很多語言都有我們感興趣的相同的核心思想，比如深度面向?qū)ο?、簡化對象（object-simplification）等等。
C#和這些別的語言尤其是Java之間的關(guān)鍵不同點是，它非常接近C++，在我們的設(shè)計中努力使然。C#從C++直接借用了大多數(shù)的操作符、關(guān)鍵字和聲明。我們還保留了許多被Java拋棄的語言特性。為什么Java中沒有枚舉，道理何在？我的意思是，拋棄它們是基于何種理論基礎(chǔ)？在C++中，枚舉顯然是一個很有意義的概念。在C#中，我們保留了枚舉并同樣使其類型安全。并且，枚舉不只是整型，它們實際上是從.NET基類庫里的System.Enum派生下來的強類型的值類型。如果沒有進行造型轉(zhuǎn)換，枚舉類型“foo”和枚舉類型“bar”不可互換。我認為這是個重要的差異。我們還保留了操作符重載和類型轉(zhuǎn)換。C#名字空間的整體結(jié)構(gòu)也非常接近C++。
但是，超越這些傳統(tǒng)的語言論題，我們設(shè)計語言的一個關(guān)鍵的目標是使C#面向組件。我們向語言自身加入了你在編寫組件時所需要的所有概念。例如properties（屬性）、methods（方法）、events（事件）、attributes（特性）和documentation（文檔），它們都是一等的語言成分。我們對特性所做的工作是全新且具有創(chuàng)新意義的，利用特性可為任何對象加入有類型的、可擴展的元數(shù)據(jù)。這在目前任何其它程序語言里都看不到。C#也是第一個合并XML注釋標簽的語言，編譯器可以用其直接從源碼中生成可讀的文檔。
另外一個重要的概念是我所說的“一站購物式軟件”（one-stop-shopping software）。一旦你用C#寫代碼，你就一體化地寫了一切。不再需要頭文件、IDL（接口定義語言）文件、GUIDs和復(fù)雜的接口。因為它是自包容的單元，所以，一旦你能夠以這種方式編寫自描述的代碼，你就可以把你的軟件嵌入到ASP頁面或植入各種不同的環(huán)境，這在以前是不可能的。
讓我們再回到這些關(guān)鍵的組件概念。語言是否應(yīng)該支持屬性或事件，業(yè)界有很多爭論。沒錯，我們是可以用方法表達這種概念。我們可以用諸如“get”或“set”之類的程序塊的命名模式，模擬屬性的行為。我們可以用接口和實現(xiàn)接口的適配器并轉(zhuǎn)發(fā)到對象。這都是可以實現(xiàn)的，正如同可以在C語言里進行面向?qū)ο缶幊桃粯?。只是它更加困難，需要更多手工勞動，為了真正表達你的思想，你最終不得不去做所有的工作。我們認為是時候了，應(yīng)該有門語言使得創(chuàng)建組件變得容易些。最近幾年來，開發(fā)人員在創(chuàng)建軟件組件。他們并不是創(chuàng)建整個應(yīng)用或整個類庫。每個人都是在創(chuàng)建從宿主環(huán)境提供的基組件繼承下來的組件。這些組件重載一些方法和屬性，它們處理事件，并把組件安裝回系統(tǒng)。樹立這些概念是關(guān)鍵的第一課。
Osborn:
你最近在介紹C#時，第一張幻燈片上面寫著：“C/C++家族里第一個面向組件的語言”。
Hejlsberg:
是的。這是我的首要目標之一。我們談?wù)撘磺腥绾味际菍ο?，這也非常關(guān)鍵。以前象Smalltalk和Lisp語言都可以這么做，但代價高昂。我認為C#包含一些優(yōu)美有趣的創(chuàng)新，以使得組件開發(fā)容易些。例如裝箱和拆箱的概念。裝箱可以使一個值類型的值轉(zhuǎn)換為一個對象，拆箱可以使一個對象轉(zhuǎn)換為一個簡單類型的值。這在以前或許也有，但我們把它應(yīng)用于語言的方式是一種優(yōu)美的創(chuàng)新。
我們努力避免以“象牙塔”的方式設(shè)計C#和.Net框架。我們承受不起重寫我們所有的軟件的負擔(dān)。業(yè)界也負擔(dān)不起，特別是今天我們正轉(zhuǎn)移到Internet時代。你要善于利用你已經(jīng)擁有的。所以，我認為互操作性也是關(guān)鍵的。我們致力于為程序員提供所有符合Internet標準的可互操作的恰當(dāng)?shù)慕鉀Q方案，例如HTTP、HTML、XML以及業(yè)已存在的微軟技術(shù)。所以你不會有如墜深淵的那一刻—發(fā)現(xiàn)新的.NET框架下沒有提供你用的一些東西，或者當(dāng)你意識到你想利用一些已經(jīng)存在的API或組件的時候。你已經(jīng)看到我們已把所有COM互操作能力內(nèi)建入語言和通用運行時；你已經(jīng)看到可以使用DllImport特性導(dǎo)入已存在的DLL（動態(tài)連接庫）；你已經(jīng)看到即使那些都不能遂你所愿，我們也有不安全代碼的概念。不安全代碼允許你編寫使用指針的內(nèi)聯(lián)C代碼，可以做不安全的造型轉(zhuǎn)換，可以抑制內(nèi)存從而使其不會被意外地垃圾收集。
關(guān)于不安全代碼有很多爭論，人們似乎認為我們在吸毒或是在干什么別的壞事。我認為這是個誤會。代碼不會僅僅因為標記了“unsafe”就表示它不受管制。當(dāng)然，我們不會扔出不安全的指針使人們?nèi)菀资艿綇腎nternet下載的不安全代碼的攻擊。不安全代碼被深深地約束在安全系統(tǒng)里。我們提供這樣的彈性：1.呆在托管代碼箱里完成工作而不會墜入深淵；2.轉(zhuǎn)入一種不同的語言使用一種不同的編程模型編寫本地代碼。如果你停留在這個箱子里，我們會使代碼更加安全，因為系統(tǒng)知道它要干什么。事實上，即使你編寫不安全代碼也并不意味著你離開了托管空間。因此，你的不安全代碼會變得更能干。
Osborn:
請給我多講一些在托管環(huán)境里處理不安全代碼的機制。
Hejlsberg:
好的。描述托管執(zhí)行環(huán)境比如Smalltalk、Java和.NET通用語言運行時一個重要特征是它們提供了垃圾收集機制。為了提供垃圾收集機制，至少要提供一個現(xiàn)代的垃圾收集器，一個“標記和清掃”垃圾收集器，比起傳統(tǒng)非托管代碼來說，你必須更多地了解正在執(zhí)行的代碼。為了找出要排除的死對象，你必須能遍歷堆棧，找到所有活動的根，并指出哪些對象是活動的哪些是不再被訪問的。然而，為了能夠達到這個目標，你必須和你執(zhí)行的代碼緊密協(xié)作。代碼要具有更好的描述性。它要告訴你它是怎么分布在堆棧里的，它的局部變量在什么地方等等。
當(dāng)你在C#中編寫不安全代碼時，你可以做不是類型安全的事，比如指針操作。當(dāng)然，標記為unsafe的代碼并非絕對執(zhí)行在不可信任的環(huán)境里。為了使之執(zhí)行，你必須授予信任，否則，代碼將不會執(zhí)行。從這一點來看，和其它本地代碼并無區(qū)別，真正的區(qū)別是它們?nèi)匀贿\行在托管空間里。你編寫的方法有一個描述表，它告訴你哪些對象是活動的，因此，不管什么時候你進入這些代碼，你都不必跨越列集邊界（marshalling boundary）。否則，當(dāng)你進入非描述性的、非托管代碼（比如通過Java本地接口），你不得不在堆棧上設(shè)置一個水印或設(shè)立一個屏障。你必須重新列集所有箱子外的引數(shù)（arguments）。一旦開始使用對象，你必須對你觸及的東西小心翼翼，因為GC（垃圾收集器）仍然在另一個不同線程里運行。如果你不使用一些隱晦的方法鎖定對象從而正確地抑制垃圾收集器，它可能會移去對象。如果你忘記那么做，那你將會不走運。
我們采用了一種不同的方式。我們說過，“讓我們集成這個到語言中去。讓我們提供聲明，例如fixed聲明，它可以讓你抑制對象以和GC協(xié)作并集成之。”用這種方法，我們提供最佳方式，帶領(lǐng)所有已經(jīng)存在的代碼一起向前，而不是僅僅將它們拋棄。這是一種不一樣的設(shè)計方式。
Osborn:
因此，你們處理的不安全代碼的內(nèi)存，實際上是在垃圾收集器的監(jiān)視之下？
Hejlsberg:
沒錯，是這樣。但是，就象所謂的“購者自慎，不包退換”一樣，它并不安全。你可以獲取指針并做錯事，當(dāng)然，你在本地代碼里也能干同樣的錯事。
Osborn:
我認為另一個易混淆的地方，是理解C#在哪兒停止以及通用運行時從哪兒開始。與它從通用運行時庫得到的相比，C#語言自身的創(chuàng)新是什么？
Hejlsberg:
好的，我想這個混淆來源于這樣一個事實：當(dāng)人們談?wù)揓ava時，他們并不真的知道哪個是語言哪個是運行時。當(dāng)人們談?wù)揓ava時，某些混淆就發(fā)生了。哪個是語言哪個是運行時？當(dāng)他們談?wù)揓ava時，他們到底指的是什么？Java，語言？Java，語法？還是Java，平臺？人們將這些不同的方面混為一談。我們的方式表明我們想成為一個多語言的平臺。我們將創(chuàng)建一個平臺，它允許你進行多語言編程，并且共享一套公共的API（應(yīng)用編程接口）。讓我們承認這一點，一些人喜歡用COBOL編程，一些人喜歡用Basic編程，一些人喜歡用C++，還有一些人將會喜歡用C#—我希望。但是，我們不會試圖告訴你，忘記你曾經(jīng)做過的所有的事情吧，我們不會說，“現(xiàn)在只有一種語言，在這個競賽中將不會有進一步的創(chuàng)新了”。我們說業(yè)界因為彈性而友好。Java是怎么來的？它的出現(xiàn)是因為在它前已經(jīng)存在一些編程語言，而在它后也還將會出現(xiàn)一些編程語言。我們想打造一個平臺，在此你可以偏愛某種語言但不會否定整個價值取向；我們想打造一個平臺，它可以是不斷革新的。今天誰在幫助COBOL程序員？又是誰將他們帶入WEB？只有在.NET平臺上你才可以把富士通COBOL嵌到ASP頁面中。我的意思是，它真正是革命性的！
Osborn:
假定.NET平臺支持多語言，那為什么選擇C#而不是Visual Basic、C++甚至COBOL？是什么使C#如此引人注目？
Hejlsberg:
首先，C#可以使我們從一張白紙開始。也就是說，我們沒有任何向后兼容的負擔(dān)。這顯然會使事情簡單些，無論從是從實現(xiàn)的立場還是從使用的立場都是這樣。例如，在C#中，我們只有一種class，并且總是被垃圾收集。而另一方面，托管C++有兩套，因為它要保留非垃圾收集風(fēng)格的程序設(shè)計。因此，在C#中，只需要你理解一些簡單的概念。
語言是一個有趣的東西，它是一種口味；語言又是一件嚴肅的事情，它是程序員選擇的一種生活方式。我是指，我們意識到我們不能走出來說，“這兒有個平臺，你只可以使用一種語言?！奔词乖谀莻€平臺上用一種語言可以干所有的事情，人們可能還是不喜歡它的語法，他們可能喜歡大括號或者一些別的程序塊分界符。那是他們熟悉的。那是使他們感覺舒服并且富有生產(chǎn)力和能力的。我們對待C#的方式僅僅是為認為語言太復(fù)雜的C++程序員和認為丟失了一些C和C++語言特性的Java程序員提供一個替代品。我們尋求一個簡化C++的方式并投入到一個多語言的平臺中，它提供更大的互操作性，并且提供完備的組件概念等等。
Goodhew:
一件有趣的事情來自于我們對開發(fā)者跟蹤調(diào)查，60%以上的職業(yè)開發(fā)人員使用兩種或更多的語言去創(chuàng)建他們的應(yīng)用。特別是當(dāng)我們問他們都用哪些開發(fā)工具的時候，我們得到的答案是：沒有哪一種面向?qū)ο蟮恼Z言將會是終結(jié)者并且所有程序員都會使用它。正如Anders早先所說，人們期望某種能夠滿足他們所做的事或他們的感覺的語法。這是一種個人選擇，這也是整個.NET平臺所關(guān)心的—提供給開發(fā)者一個語言實現(xiàn)選擇。我想我們做了件漂亮的工作。你基本上可以在Visual Basic.NET和C#中做同樣的事情。Visual Basic對于大多數(shù)程序員來說仍然是易于接受的。C#則具有更多的活動空間并且比VB更富威力。
Osborn:
這意味著在C#中可用更少的聲明實現(xiàn)更多？
Hejlsberg:
是的。意味著通過不安全代碼，你可以得到更多的能力。
Osborn:
也就是說，不能在VB中寫不安全代碼？
Hejlsberg:
是的。不可以。
Goodhew:
但是，基本上，兩種語言可以做同樣的事。和Visual Studio 6相比，這是一個根本性的改變。在Visual studio 6.0中，如果你想創(chuàng)建多線程的MTS對象，并且你是一個VB程序員，你就沒招。你不得不用C++。現(xiàn)在，有了.NET框架，你可以使用任何一種你喜歡的語言。
Hejlsberg:
這就是我在一般會議談話里說過的，.NET框架提供一致的編程模型。在語言和框架的進化過程中，我們似乎一貫都是把一種程序語言綁死在特定的API和特定的編程方式上。VB是快速應(yīng)用開發(fā)工具；MFC（微軟基礎(chǔ)類）是子類化的方式；ASP則是把東西塞到Web頁面中。在每一種情況下，你對編程模型的選擇總是決定了你對程序語言和可使用的API的選擇。每次當(dāng)你變換框架時，都增加了你學(xué)習(xí)新語言和API負擔(dān)的工作量。我們真正試圖統(tǒng)一這一切，我們提供一套API，一套支持可視化設(shè)計的工具，我們還提供一個可以任選一種適合你的語言的彈性。
Osborn:
我不知道這對那些使用象VBScript和Jscript腳本語言的有什么用？
Hejlsberg:
.NET框架下奇妙的事情之一是使腳本語言能夠編譯。看看ASP+（譯注：今天稱為ASP.NET），現(xiàn)在，實際上，在你的頁面里運行的是真正編譯過的代碼。它不是遲綁定的、調(diào)度查找的—如果用戶沒有點擊頁面，你就不會看到運行時錯誤。ASP+開發(fā)者可以使用Visual Basi.NET完全的威力而不是VBScript。并且第一次，他們可以使用Perl、Python以及其它流行語言，如果他們這么選擇的話。
Petrusha:
服務(wù)端的JavaScript現(xiàn)在也能被編譯？
Hejlsberg:
是的，沒錯。
Goodhew:
.NET框架使得使用腳本語言就象用具有完全特性的語言一樣，因為它們現(xiàn)在訪問的是一個真正的編程框架，并且訪問的是同一基類API。你應(yīng)該看看搞JScript實現(xiàn)的伙計們都已經(jīng)完成了什么。（編注：JScript是微軟對ECMA 262語言規(guī)范(ECMAScript 版本 3)的實現(xiàn)，只有一些很小的例外（為了保持向后的兼容性），JScript是對ECMA標準的完整實現(xiàn)）。所以.NET平臺提供了一個通用語言框架，對腳本寫作者來說，具有極大的好處。
Osborn:
我們已經(jīng)討論關(guān)于Java、C++和腳本語言。在PDC上，我聽到很多人爭論.NET IL（IL是微軟中間語言，所有編譯器都必須產(chǎn)生它以運行在.NET框架上）和運行于Java虛擬機中的Java字節(jié)碼沒什么兩樣。從你的談話中，顯然你并不同意這一點。你介意進一步評論它們之間的區(qū)別嗎？
Hejlsberg:
我當(dāng)然不同意這種說法。首先，ILs的思想是一種非常老的思想了。你可以追溯這個概念到UCSD Pascal p-machine（一個早期的個人計算機Pascal實現(xiàn)）或者Smalltalk。P-code曾被Basic和Visual Basic使用，Word的一個組成部件，內(nèi)部使用p-code引擎，因為它更精簡。所以，p-code根本就不是什么新玩意。
我認為，我認為我們使用的IL的方式對此感興趣：我們給你一個選擇—如果你愿意—你可以控制將IL編譯或翻譯為本地代碼的時機。實際上，使用managed C++，你可以直接從源程序生成本地代碼。Managed C++還可以生成IL，就象C#和VB那樣。當(dāng)你安裝你的代碼時，我們給你一個編譯選項，可以把IL編譯成本地代碼。因此，當(dāng)你運行它們時，就不會有即時編譯負擔(dān)。我們還給你提供了一個動態(tài)運行和編譯代碼的選項：即時編譯。有了IL，就給你帶來了很多便利，比如它提供了這些能力：移植到不同的CPU架構(gòu)，引入真正的類型安全，并在此之上構(gòu)建安全系統(tǒng)。
我認為我們的IL設(shè)計和Java字節(jié)碼關(guān)鍵區(qū)別在于，我們做出了超前的決定—不用解釋器。我們的代碼永遠本地運行。因此，即使產(chǎn)生IL，你也從來都不會運行解釋器。我們甚至還提供了不同風(fēng)格的JITs。對于精簡框架（compact framework），我們有EconnoJIT，就象我們稱呼它的一樣，它是一個非常簡單的JIT（編注：.NET Compact是.NET framework的一個子集，是為移植到其它設(shè)備和平臺而設(shè)計的）。對于桌面版，我們有完備功能的JIT。我們甚至有可和我們的C++編譯器共用一個后端的JIT。不過，這都會比較耗時，因此你只應(yīng)該在安裝時使用它們。
一旦你做出偏向于執(zhí)行本地代碼而不是解釋代碼的決策，它就會強烈地影響IL的設(shè)計。它改變了應(yīng)該包括那些指令，應(yīng)該包括哪些類型信息，以及它應(yīng)該如何表達。如果你仔細看看兩種IL（譯注：即.NET IL和Java字節(jié)碼），你就會注意到它們很不一樣。從某種意義上講，我們的IL是類型中立的。指令里沒有指定引數(shù)類型的信息。進一步來說，它是靠已經(jīng)壓棧的東西推斷出來的。這種方式使IL更為精簡。無論如何，一個JIT編譯器需要知道那些信息，因此沒有理由在指令里攜帶它們。所以，我們最終做出了不一樣的設(shè)計決策，而這使得容易把IL翻譯成本地代碼。
Osborn:
解釋方式和你描述的方式有何不同？
Hejlsberg:
解釋器的核心是一個循環(huán)—從p-code流取得一些字節(jié)，然后進入一個大大的switch聲明，“哦，這是ADD指令，因此它到這兒來，但這不是…”等等。
解釋器模擬CPU。我們反其道而行之，我們只走一條道，我們一直都走一條道，我們把指令翻譯為機器碼?，F(xiàn)在，在EconoJIT的情況下，機器碼實際上非常簡單，它只創(chuàng)建一個調(diào)用和壓棧指令的列表，并且調(diào)用運行時輔助器，然后運行時輔助器引發(fā)這個列表。當(dāng)然，這個代碼比解釋的代碼執(zhí)行得快。
Osborn:
讓我用一句話來總結(jié)一下：你們完全編譯代碼。因此當(dāng)你編譯完時，bits已經(jīng)完全準備好運行了，盡管從IL翻譯成機器碼的時機可能不一樣。
Hejlsberg:
是的。但是，如果是在一個內(nèi)存受限的小設(shè)備的環(huán)境里，運行完就可將代碼丟棄掉。
Osborn:
讓我們進入語言的語法細節(jié)。我在想，C#是否包括對正則表達式的內(nèi)建支持。我沒有在語言參考里看到它，或許它可能在別的什么地方吧。
Hejlsberg:
首先，在基類庫里有一個正則表達式類。我們并沒有在語言里加入對正則表達式的任何直接支持，但是，實際上我們有些非常類似的特性。并不值得對它們做重大的處理。但是，比方說，當(dāng)你需要指定一個時候，我們給你這個能力：逐個字寫一個字符串而無需每次寫兩個后斜杠。當(dāng)你寫正則表達式時，并且當(dāng)你的正則表達式里的引號還套引號時，它實際上有很大的幫助。雖然就總體而言，這點幫助不足掛齒，但顯然其核心在.NET框架之中，而這個框架可以被任何編程語言共享。
Osborn:
C#和Java名字空間看起來不同。它們是否概念相同而實現(xiàn)上不同？
Hejlsberg:
概念上是的，但是在實現(xiàn)上，差別很大。在Java里，包的名字也是物理意義上的東西，它指示了你的源代碼文件的目錄結(jié)構(gòu)。在C#中，物理包和邏輯名稱完全獨立，無論你如何稱呼你的名字空間，它都和你的實際代碼的物理包不相關(guān)。這就給你更多的彈性—將物理上分布的單元包裝在一起，并且不強迫你建很多的目錄。在語言自身，有一些很明顯的區(qū)別。在Java里，包也是你的物理結(jié)構(gòu)，因此，Java源文件必須在正確的路徑里，并且只能包含一個公用類型或者一個公用類。因為C#沒有那種物理和邏輯上的綁定，所以你可以任意命名你的源文件。每一個源文件都可以被多個名字空間使用并且可以帶有多個公用類。進一步而言，假如你喜歡的話，你可以把所有的源碼寫在一個大文件里，或者可以把它們分散到的小文件中去。概念上講，C#編譯時發(fā)生了什么—你給編譯器提供了所有構(gòu)成你的項目的源文件，然后它只管前進并指出該干什么。
Osborn:
我有一個關(guān)于泛型編程的問題：你認為它是個重要的概念嗎？它應(yīng)該成為面向?qū)ο笳Z言的一部分嗎？如果是的話，你們把泛型編程加為C#的一部分的計劃如何？
Goodhew:
唔，在第一個版本里納入泛型編程的愿望受到了限制。因為，并不象每一個人以為的那樣，微軟并沒有無限的資源。對于在這第一個版本里該有些什么東西，我們不得不做出一些困難的決定。
Osborn:
有多少人參與開發(fā)C#？
Hejlsberg:
語言設(shè)計組由4個人構(gòu)成，編譯器組由另外五個開發(fā)人員構(gòu)成。
Petrusha:
框架呢？
Hejlsberg:
那就多了，整個公司都被卷進來了。
Goodhew:
就整個Visual Studio和.NET平臺團隊而言，我們的部門大概有千人左右。包括程序管理人員、開發(fā)人員、測試人員，包括所有構(gòu)建函數(shù)、框架、運行時、ASP編程模型的人員以及其它所有的人，比方說，我自己，管理層的。
Hejlsberg:
就你剛才所說的泛型方面，我明確地認為它是個非常有用的概念，并且你當(dāng)然可以列舉出發(fā)生在學(xué)術(shù)界和業(yè)界所有的泛型研究。模板是該問題的一種解決方案。在我們內(nèi)部討論中，我們決定要在新平臺里做這件事情。但我們真正喜歡做的是讓泛型能夠被底層的運行時所理解。這和如何創(chuàng)建泛型原型是不同的。使用Java的“擦除”概念，系統(tǒng)里沒有真正的泛型信息。如果通用語言運行時理解泛型的概念，多種語言就可以共享這個功能。你可以在一個地方用C#寫一個泛型類，別的人用別的語言也可以使用它。
使泛型成為運行時的一部分，還可以使你能夠更有效率地做某些事情。泛型實例化的最理想的時間是在運行時。如果用C++，模板的實例化發(fā)生在編譯時，你有兩種選擇：聽任你的代碼膨脹或試圖在鏈接時去除掉一些膨脹代碼。但是，如果你有多個應(yīng)用，你可能會忘記這一點，你將只能得到膨脹的代碼。
如果把泛型的知識納入通用語言運行時，那么，運行時就可以理解—當(dāng)一個應(yīng)用或組件請求一個“Foo”列表時，它首先會問：“我已經(jīng)有了一個實體化的“Foo”列表了嗎？”如果是，就用那一個。實際上，如果Foo是一個引用類型，并且我們設(shè)計得當(dāng)?shù)脑?，我們可以讓所有引用類型共享一個實體。對于值類型，比如整型和浮點型，我們可以為每一個值類型創(chuàng)建一個實體，但這應(yīng)該在應(yīng)用請求時才做。為了把泛型加入運行時，我們已經(jīng)做了大量的設(shè)計工作和必要的基礎(chǔ)性工作。
你先前提到的關(guān)于IL的東西是有意思的，因為加入泛型的決定影響了IL的設(shè)計。如果IL指令嵌入類型信息，比方說，假如一個“加”指令不再是個“加”了，而是一個整數(shù)“加”或是浮點數(shù)“加”或是一個雙精度數(shù)“加”，你就把類型信息硬加入到了指令流里，在這一點來說，IL不是泛型的。我們的IL格式實際上是真正的類型中立的。并且，為了保持類型中立，我們可以遲些時候加入泛型且不會給我們帶來麻煩，至少不會太麻煩。這也是我們的IL和Java的字節(jié)碼看起來不一樣的原因之一。我們IL類型中立。“加”指令可以加棧頂?shù)娜魏蝺蓚€東西。在泛型世界，當(dāng)它被實體化時，它可以被轉(zhuǎn)換成不同的代碼。
Osborn:
所有.NET語言都可獲得泛型能力嗎？
Hejlsberg:
是的。微軟劍橋研究院已經(jīng)創(chuàng)建了一個支持泛型能力的通用語言運行時和C#編譯器的版本，我們正在研究如何盡快使其前進。第一個版本是不可能加入泛型了，我們知道的就這么多。但是我們正在工作，以確保我們在第一個版本里做了正確的事情，從而使泛型可以適用于整個藍圖。
Osborn:
C#和.NET框架以及Visual Studio的下一個版本計劃發(fā)行日期是？
Goodhew:
唔，我們?yōu)閬磉@兒參加PDC的6500名人員帶來了技術(shù)預(yù)覽版。我們希望2000年秋季的某個時間發(fā)布beta版，然后在準備好以后，我們發(fā)布正式版。我們所做的一件真正令人激動的事情是看看Windows2000發(fā)行版發(fā)布進行的如何，以讓關(guān)鍵客戶參與到合作開發(fā)和合作部署的進程中來。關(guān)于.NET框架和Visual Studio.NET，我們將再次和客戶協(xié)作，以決定最終產(chǎn)品的發(fā)行日期。我們打算讓他們告訴我們什么時候產(chǎn)品該就緒了。并且，因為有真正的客戶參與到這個進程中來，我們應(yīng)將獲得更好的產(chǎn)品質(zhì)量。這種做法的不利的一面是使產(chǎn)品開發(fā)和發(fā)布的進程有點不確定。但這是一種根本性的改變。我們正在尋找一種打破質(zhì)量障礙的產(chǎn)品發(fā)行方式，而不僅僅是挑一個武斷的日期說我們要發(fā)貨了。
Osborn:
因此，不是一個代碼完成的日期，我們正在尋找一個“準備好出發(fā)”的日期？
Goodhew:
是的，沒錯。我認為開發(fā)者將會發(fā)現(xiàn)Visual Studio.Net發(fā)行版是微軟歷史中最高質(zhì)量的發(fā)行版本之一。
Osborn:
你們已經(jīng)把C#提交給ECMA（譯注：歐洲計算機制造商協(xié)會）。標準化真的是一個嚴肅的目標嗎？你希望在其它平臺上也可使用C#嗎？
Hejlsberg:
的確如此！把C#作為一個可能的標準提供給業(yè)界當(dāng)然是我們的目標，這也是我們把它提交給ECMA的原因之一。在引導(dǎo)這個有著通用語言基礎(chǔ)設(shè)施的公共設(shè)計的語言的進程中，（？？）我們當(dāng)然希望得到ECMA的支持。關(guān)于通用基礎(chǔ)設(shè)施，我的意思是指這個規(guī)范所規(guī)定的一套核心類庫集，如果其它公司使用其它平臺實現(xiàn)它，他們有理由期望發(fā)現(xiàn)可以在他們的程序里利用這些類。
Goodhew:
我想指出的是我們正在和ECMA做真正的開放標準。當(dāng)ECMA為C#和通用語言基礎(chǔ)設(shè)施達成標準后，在ECMA的版權(quán)和許可政策下，真正的開放將可實現(xiàn)。任何客戶、任何人都可以許可ECMA C#標準，子集之，超集之，并且無需付版稅。他們可以在任何平臺上或任何設(shè)備上實現(xiàn)之。我們完全希望人們那么做。這和我們的競爭者根本不同，他們徘徊在標準之外，尋找某某人去為他們私有的語言貼上印花。
John:
我在早餐和午餐時聽說：“假如微軟沒有把COM搞到基礎(chǔ)設(shè)施中去，平臺會具有多么真正可能的可移植性？”
Hejlsberg:
完全可能。COM并非C#和通用語言基礎(chǔ)設(shè)施標準化之必須。根本不是。C#有一個完備豐富的類模型，而COM則是從另外一個視角看待應(yīng)用的互操作性。但是，C#和通用運行時的核心中從未說過必須要有COM、GUID、HRESULT、AddRef或Release等等。一個都沒有。.NET通用語言運行時徹底摒棄了COM，但它還是給了你巨大的COM互操作能力。鑒于先前所述，我仍然認為它將非常重要，但絕非不可或缺。
Goodhew:
我認為這些評論起因于我們公開的最初版本的語言規(guī)范。微軟在某次會議上把它寫進了規(guī)范。在那次會議上，我們認為按照微軟平臺來說這是非常重要的。結(jié)果，我們在規(guī)范里多次引用COM和DLL這樣?xùn)|西。DLL是如何在已給定平臺上，激活本地代碼的更多的一般性問題中的一個特例。對于納入標準化組織以及和象IBM的人（我們和他們一起制訂SOAP規(guī)范）協(xié)作的一個好處是，可以確保我們不做任何這樣的提及，以防止在規(guī)范的未來版本里，把我們自己綁死或鎖定在象COM框架這樣的東西上。
就象Anders說的那樣，COM互操作能力和COM支持對我們和現(xiàn)有的微軟客戶來說是極其重要的。我認為為了在.NET上支持COM我們做了偉大的工作。但是，業(yè)界的人們已經(jīng)閱讀了大量的我們對COM和DLL字眼引用的東西，他們由此推論.NET平臺僅僅是為Windows平臺而設(shè)計的，這絕對是錯誤的。
Hejlsberg:
并且，我認為就象COM互操作能力對于微軟和在微軟平臺上構(gòu)建解決方案的客戶很重要一樣，C#和通用語言基礎(chǔ)設(shè)施的標準化，將允許在任何其它平臺上實現(xiàn)這門語言，以加入意義重大的平臺互操作能力。
Osborn:
所以你們將不會堅持應(yīng)該有個什么“純C#”和“純.NET”的實現(xiàn)？
Hejlsberg:
什么叫“純”？真正有多少“純”Java應(yīng)用存在？我冒險猜測一下，非常非常少。那就是我估計的數(shù)量。讓我們承認這一點，人們希望能夠利用他們已有的代碼。不可能叫那些公司把什么東西都扔掉。
Goodhew:
你和Roger Sessions交流過嗎？（編注：Roger Sessions是ObjectWatch公司的總裁，并且是《COM+ and the Battle for the Middle Tier》的作者） 。
Osborn:
沒有。
Goodhew:
Roger談到了EJB（Enterprise JavaBeans）規(guī)范的相關(guān)章節(jié)，那兒講了廠商許可擴展。毫不奇怪，廠商擴展包括諸如事務(wù)管理、安全、消息技術(shù)以及其它更多的方面，這在構(gòu)建企業(yè)級系統(tǒng)中是相當(dāng)重要的。在一篇文章[譯注：http://www.objectwatch.com/issue_24.htm]里，Sessions粗略地列舉了11個領(lǐng)域的機能，這是可容許的廠商規(guī)范實現(xiàn)。因此，如果你選擇IBM Websphere作為你的EJB實現(xiàn)，你為你的EJB應(yīng)用寫的代碼將不可避免地把你鎖在Websphere上。Java是100%純和100%可移植的概念是不真實的。在IBM的開發(fā)者工作站點上，有一個對James Gosling的偉大的專訪（譯注：http://www-106.ibm.com/developerworks/features/gosling/index.html）。James Gosling直接指出了這一點。他說，是的，整個“寫一次到處運行”、“100%純的東西”真是個愚蠢的想法，更多的是屬于營銷上東西。他說，實際上，“我們并不認為我們能夠交付所有這一切，基本上，我們辦不到”。這就是這種語言的發(fā)明者所說的，并不存在什么純粹性和可移植性。
Osborn:
我們有沒有遺漏一些沒透露的C#的偉大的特性或創(chuàng)新，你愿意補充一下嗎？
Hejlsberg:
關(guān)于整個.NET框架，隱含地，也包括C#，我想提的一點是：它是構(gòu)建分布式應(yīng)用的手段。并非很久以前，我們創(chuàng)建兩階層的客戶機/服務(wù)器應(yīng)用，然后對象協(xié)議如CORBA、IIOP、RMI和DCOM接踵而至。這種類型的編程是EJB（以CORBA或RMI為基礎(chǔ)而實現(xiàn)）的基礎(chǔ)。我們已經(jīng)會構(gòu)建這種強連接式的分布式系統(tǒng)，但它們不具備伸縮性。它們在WEB上不能夠伸縮因為它們是有狀態(tài)的，它們在服務(wù)端保持狀態(tài)，你不能夠轉(zhuǎn)入另一臺機器，把它插入并讓相關(guān)東西復(fù)制自己。
當(dāng)初，當(dāng)我們坐下來著手設(shè)計.NET框架時，我們回頭看了看Web上究竟發(fā)生些了什么。它正在變成松散連接、非常分布式的世界。我們努力理解它對潛在的編程模型的影響。因此，我們從根本上假定分布式應(yīng)用是以松散連接、無狀態(tài)風(fēng)格構(gòu)建的，我們做出的設(shè)計可提供巨大的伸縮性，你只管擴展。你轉(zhuǎn)入更多的框架并把它們插入。一旦做出了這個根本性的假設(shè)，一切就隨之改變。它改變了怎樣設(shè)計你的基本服務(wù)，怎樣設(shè)計你的消息技術(shù)，甚至怎樣設(shè)計你的用戶界面。這是一個新的編程模型。我們已經(jīng)決定使用XML和SOAP作為使這個模型工作的方式。它們被深深地集成進.Net，并且這種集成對于我們在設(shè)計.NET框架時做出的每一個決策是如此核心，以至于它不是那種你只進來蜻蜓點水地逛一逛就可以的東西。
Osborn:
你能指出一些對程序員來說明顯特別的地方嗎？
Hejlsberg:
一個相當(dāng)好的例子是XML是如何被集成到C#中的。C#中有特性（attribute）的概念，它允許你向類型和成員加入宣告性的信息。就象你可以說某個成員是公用的或私用的一樣，你可能還想說這個是事務(wù)的，或者這個假定是個Web service，或者這個假定可以序列化為XML。因此，我們加入特性以提供一般性機制，但我們在所有Web service和XML基礎(chǔ)設(shè)施中都用到了它。我們還給你用特性修飾類和字段的能力。在你的類中，你可以說“當(dāng)這個類變成XML時，它應(yīng)該變成“this”標簽名，并且屬于“this”XML名字空間?！蹦銓⒛軌蛑付ㄒ粋€字段變成一個元素，而另外一個變成一個屬性（譯注：attribute，此處指XML中的屬性）。你還能夠控制XML的模式（譯注：即schema）；在你的聲明類的地方控制它，這樣，所有附加的宣告性的信息就都有了。一旦以該方式正確地使用特性修飾你的C#代碼，系統(tǒng)就可以簡單地把一個特定的類轉(zhuǎn)化成XML，在線上傳輸，當(dāng)它傳回時，就可以在另一端重建該對象。這都是在一處定義完成的。它不象傳統(tǒng)的定義文件或雜七雜八的信息和命名模式，它就在那兒。當(dāng)你在IDE中創(chuàng)建它們時，它就給了你完整的聲明。我們還可以提供更高級的工具，讓它幫你做這個事。
我知道我有點離題了，但我們提供的這些基礎(chǔ)設(shè)施的確令人興奮。單單因為我們有這些特性，你就可以請求XML序列化基礎(chǔ)設(shè)施或Web service基礎(chǔ)設(shè)施把已給出的類轉(zhuǎn)換成XML。當(dāng)你這樣做時，我們實際上將為這個類配上XSD schema，并且，我們將創(chuàng)建一個專門化的解析器，它是從我們一般的XML解析器（它是.NET基類的一部分）派生下來的，并且覆寫方法，并向解析器加入邏輯，因此它是專門為那個模式服務(wù)的。我們已經(jīng)實體化好一個解析器，可以本地代碼的速度解析XML。如果它不正確，我們將給你一個體面的出錯信息，它可以精確地告訴你是什么出了問題。我們可以在代碼緩存基礎(chǔ)設(shè)施中緩存它，它將坐等直到下一次一個具有同樣模式的類來臨并將發(fā)生作用，“嘭！”，我的意思是，難以置信，難以置信的處理能力！
Osborn:
所以，下面的確有許多有意思的引擎...
Hejlsberg:
Yeah。我認為，對于在這個領(lǐng)域里達成此種思想，我們是領(lǐng)先的一代。
Osborn:
精彩之至。謝謝，耽誤你時間了。
Hejlsberg:
不客氣。
