C# 默认接口方法更新完成,很多细节问题尚待解决


随着对默认接口方法的支持越来越接近完成,一些潜在的问题被提了出来。虽然已经完成了很多工作,但这是一个复杂的特性,许多细节问题还没有解决。但首先,这里有一些已解决的问题。

接口允许使用 static 和 const 字段了。

除 == 和!= 之外的操作符也可以在接口中实现。在类中定义的操作符总是优先于接口中定义的操作符,即使接口中定义的操作符更具体。同样,接口中适用的操作符会覆盖基接口中的操作符。

现在,在调用基类方法时可以跳过类了,下面这段话证实了这一点:

我们认为,我们已经批准使用新的 base(Type) 语法,其中,Type 是类类型(例如,跳过一个基类并调用基类的基类),但是我们应该明确地确认这一点。我们还应该确认 base(Type).M() 可能引用一个非虚成员 M。我们还应该确认一个可访问性需求:这个查找找到的 M 必须在调用发生的地方可访问(即通常的名称查找约束)。

在接口中声明受保护方法的特性仍然存在一些疑问,尽管它暂时得到了批准。

当一个类实现了一个方法,但是它的子类将其标记为抽象方法,这被称为“重新抽象(reabstraction)”。这是 Java 互操作性必需的,但是确切的语法仍然没有确定。本质上,问题是是否需要 abstract 关键字。此外,他们“需要确保运行时 [团队] 同意实现重新抽象”。

接口中的普通属性是抽象的,尽管它们看起来像类中自动实现的属性。但是,如果属性是静态的,它就不能是抽象的。这是否意味着在默认情况下,接口中声明的静态属性是自动实现的?

类中的分部方法被认为是私有的,因为它们没有可访问性修饰符。但是在接口中,缺少可访问性修饰符意味着该方法是公共方法。接口中分部方法的规则是什么?它们允许、不允许还是需要 private 关键字?

在默认方法中,object.MemberwiseClone() 是否可以访问?

最后,是否应该将该特性的正式名称命名为 RuntimeFeature.DefaultInterfaceImplementation?答:“LDM 并不关心它的名称。”

本文文字及图片出自 InfoQ

你也许感兴趣的:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注