在 C# 的未来版本中是否有任何“扩展属性”计划？

Question

我之前也想过这个问题，在阅读this问题时又想到了这个问题。

在未来的 C# 版本中是否有“扩展属性”的计划？

在我看来，使用更多“编译器魔法”来实现它们可能非常简单。例如，在扩展方法名称上使用 get_ 和 set_ 前缀会将该方法转换为扩展属性：

    public class Foo
    {
        public string Text { get; set; }
    }
    public static class FooExtensions
    {
        public static string get_Name(this Foo foo)
        {
            return foo.Text;
        }
        public static void set_Name(this Foo foo, string value)
        {
            foo.Text = value; 
        }
    }

是否有任何技术限制可以防止这种情况发生？这会在幕后产生太多的东西吗？不够重要，不值得付出努力？

Answer 1

功能请求的官方网站是http://connect.microsoft.com/VisualStudio。

已有扩展属性here的请求。

微软在 2008 年 7 月 29 日的回答包括以下内容：

扩展属性是常见的 请求，我们实际上已经走了很远 与下一个版本的设计 语言，但最终不得不 因各种原因报废 困难。它仍然在我们的 雷达。

Answer 2

一般来说，我认为这会鼓励不良做法。

属性应该代表所讨论对象的某种状态，而方法应该代表工作单元。但是许多开发人员倾向于将计算密集型或运行时间相对较长的代码放在更适合作为方法的 getter 和 setter 中。

扩展对象不与派生对象相同。如果您需要添加属性，从哲学的角度来看，您正在谈论需要向对象添加状态信息。这应该通过从类派生来完成。

Answer 3

虽然我不认为您提出的建议是一个好主意，但您可以使用 C# 4 中即将推出的 dynamic 类型获得几乎相同的东西。计划的一部分是允许新的属性和方法在运行时添加到现有对象和类型。一个区别是您不会对扩展属性进行编译时检查。

Answer 4

对于这种把戏，可能有话要说。

只需查看 WPF 中的附加属性。它们确实为陈述性行为依恋提供了巨大的力量。但我不确定在声明性上下文之外会是什么样子......

Answer 5

我不确定这将如何工作。扩展必须是静态的，因此属性本身也必须是静态的。这意味着您用来支持这些属性的任何东西也都是静态的。但预计您对这些的计划使用期望它们与this 关键字指示的实例相关联，而不是类型本身。

Answer 6

“扩展属性”现在可以通过继承获得。添加这样的野兽会鼓励糟糕的 oop 实践，而且通常麻烦大于其价值。