歡迎光臨
每天分享高質量文章

C# 預設接口方法更新完成,很多細節問題尚待解決

隨著對預設接口方法的支持越來越接近完成,一些潛在的問題被提了出來。雖然已經完成了很多工作,但這是一個複雜的特性,許多細節問題還沒有解決。但首先,這裡有一些已解決的問題。

接口允許使用 static 和 const 欄位了。

除 == 和!= 之外的運算子也可以在接口中實現。在類中定義的運算子總是優先於接口中定義的運算子,即使接口中定義的運算子更具體。同樣,接口中適用的運算子會改寫基接口中的運算子。

現在,在呼叫基類方法時可以跳過類了,下麵這段話證實了這一點:

我們認為,我們已經批准使用新的 base(Type) 語法,其中,Type 是類型別(例如,跳過一個基類並呼叫基類的基類),但是我們應該明確地確認這一點。我們還應該確認 base(Type).M() 可能取用一個非虛成員 M。我們還應該確認一個可訪問性需求:這個查找找到的 M 必須在呼叫發生的地方可訪問(即通常的名稱查找約束)。

在接口中宣告受保護方法的特性仍然存在一些疑問,儘管它暫時得到了批准。

當一個類實現了一個方法,但是它的子類將其標記為抽象方法,這被稱為“重新抽象(reabstraction)”。這是 Java 互操作性必需的,但是確切的語法仍然沒有確定。本質上,問題是是否需要 abstract 關鍵字。此外,他們“需要確保運行時 [團隊] 同意實現重新抽象”。

接口中的普通屬性是抽象的,儘管它們看起來像類中自動實現的屬性。但是,如果屬性是靜態的,它就不能是抽象的。這是否意味著在預設情況下,接口中宣告的靜態屬性是自動實現的?

類中的分部方法被認為是私有的,因為它們沒有可訪問性修飾符。但是在接口中,缺少可訪問性修飾符意味著該方法是公共方法。接口中分部方法的規則是什麼?它們允許、不允許還是需要 private 關鍵字?

在預設方法中,object.MemberwiseClone() 是否可以訪問?

最後,是否應該將該特性的正式名稱命名為 RuntimeFeature.DefaultInterfaceImplementation?答:“LDM 並不關心它的名稱。”

赞(0)

分享創造快樂