.NET API審查第二部分

jopen 9年前發布 | 5K 次閱讀 .NET

本文是對于1月14日所進行的.NET API審查會議的分析的第二部分。這篇報告中涵蓋了HashSet、RegEx、Process.Start、Immutable collections和BitVector32等API的相關討論。

這一條意見毫無爭議地通過了，只是讓人有些疑惑的是，為什么原始版本中竟然會不支持這一特性。

目前，RegEx解析器采取了一種快速失敗的方法。這就意味著，如果在某個正則表達式字符串中存在多個錯誤，解析器只會報告第一個錯誤的存在，并且會立即中斷解析過程。

這一建議的關鍵就在于希望獲取更多的信息。在理想的情況下，解析器應當返回一個錯誤集合，以顯示正則表達式中的所有問題。但這就需要解析器嘗試從錯誤中進行恢復，繼續解析之后的表達式內容，并尋找其它錯誤。

對此建議的一個顧慮在于，如果接受了這一建議。接下來就會有人提出進一步的要求，例如自定義高亮、代碼自動完成等等，以便在Roslyn中進行使用。而這種要求已經遠遠超出API的范圍了，因此評審團隊擔心，一旦接受了這一建議，遲早都會需要一個新的API。

結論： 分別討論兩組建議。

一個建議是在RegEx在解析過程中出錯時，對RegEx拋出的異常信息加以改善。這里只會包含一些基本信息，例如第一個錯誤的具體位置，前提是這種方式不會讓代碼產生太多重寫要求。

第二個建議是，是否應該添加對應的TryParse方法。

RegEx API并不會擴展到這種可以支持IDE的程度。

這一條建議本身非常簡單，就是重新引入這個存在于Windows桌面版的.NET中的方法，并將其擴展至跨平臺版本的.NET中。不考慮兼容性問題的話，那就是簡單地從原始版本中進行拷貝粘貼而已。

表面上看，這個問題十分簡單。在Windows中，句柄可以在子進程中繼承，這可能會導致預料之外的問題，例如Notepad可能會持續保持一個打開的TCP socket，即使在父應用嘗試關閉它之后。這個新的參數則能夠讓用戶選擇不繼承句柄。

問題在于，這種處理在Linux環境下毫無意義。在Windows下創建子進程會使用一個全局的配置，而Linux則允許在創建句柄時指定每個句柄是否能夠被繼承。

一種建議是為句柄繼承提供一個三態的屬性：操作系統默認、繼承句柄，以及不繼承句柄。

另一種建議是創建一個基礎版本的ProcessStartInfo方法，并且只提供跨平臺的選項。然后通過創建子類的方法實現Linux、Win32和Windows Shell Execute的特定功能。

結論： 提供一個新的屬性，其類型為現有的HandleInheritability枚舉，其中包含兩個狀態值。

要確保對一個可變集合的變更是線程安全的，你必須獲得對該集合的一個引用，創建一個替代的列表，并嘗試調用 Interlocked.CompareExchange 來決定是否能夠成功地替換原始列表。如果另一個線程在同一時間要覆蓋該集合，該方法會返回false，你必須重新啟動該過程以再次嘗試。

ImmutableInterlocked 能夠簡化一些基礎操作的過程，例如添加或移除集合的項。你仍然需要在循環中使用它，但可以避免對本地變量的處理。

下一個建議是增加一個相應的泛型實現，其中可以接受一個lambda表達式進行某些操作。從技術上來說，這個泛型實現會使其它實現方式都變成多余的了，但既然那些實現已經發布，也不可能刪除它們了。

結論： 決定添加這個新方法。

有一個問題是，是否要將那些多余的方法標記為過期。

結論： 由于那些多余的方法依然可以正常工作，因此不應該標記為過期。

BitVector32 能夠以一個比特和小整數數組的形式表現一個整數值。該類型存在于System.Collections.Specialiazed命名空間中，這個命名空間通常被基礎類庫團隊當作遺留代碼，沒人敢去動其中的內容。

與之相關的一個問題是 BitArray 類，如果不把BitVector32當作遺留代碼處理，那么它就應當和BitArray中的功能相一致。

對于該提議尚未得出任何結論，稍后將會再次對此展開討論。

本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/news/view/7161c2