我一直希望这能使界面流畅。例如，请参阅此Channel9讨论。可能还需要添加索引属性。

你觉得呢？你有没有什么想法？优势会超过"语言混乱"吗？

解决方案

由于属性只是方法的语法糖，我不明白为什么Cshould拥有没有扩展属性的扩展方法。

不知道为什么属性只是具有不同语法的getter / setter方法。

我想这会很好，只要使用它们对性能没有影响或者影响很小。

一定会增加我们可以使用的工具种类。

现在，就我的观点而言，是的，他们应该这样做，但是像其他任何东西一样，开发人员需要在需要时正确使用它。像大多数新功能一样，许多开发人员在没有充分了解它们以及何时/如何/在何处/如何最好地使用它们的情况下使用它们。我知道有时我也会对此深深吸纳。

但是，是的，请带上它。我可以看到自己在某些情况下使用它

我猜索引属性将只是一大堆我们在4.0中将看到的重大增强功能中的填充物。

我认为扩展属性几乎没有用。我发现自己主要使用属性来封装字段(经典的get； set；)或者提供只读的优点(只是私有，只读，构造函数设置的字段上的get)。由于扩展无法访问私有成员，因此我并没有真正理解这一点，尤其是对于" set;"而言。做任何事情，都要"设置"；无论如何都只需要调用其他方法。然后，我们会遇到引发异常的属性问题。
由于扩展仅限于使用公共属性和方法，因此我发现使用实用程序类的代码更干净，更容易阅读。归根结底，我们正在使用扩展方法使LINQ看起来很漂亮。为了防止开发人员做错事，我可以在LINQ中到处处理一个额外的()并坚持使用扩展方法。

不，属性只是隐藏为代码真正生成的内容的一种方法。如果我们查看反射的代码或者IL，则可以确定我们真正得到的是以下内容：

public string MyProperty { get; set; }

变成

public string get_MyProperty(){ return <some generated variable>; }
public string set_MyProperty(string value) { <some generated variable> = value; }

这只是2种方法。

似乎很容易被滥用。正如其他人所提到的，Cproperties只是方法的语法糖。但是，将其实现为属性具有某些含义：访问不会有副作用，并且修改属性应该非常便宜。后一点至关重要，因为延伸性能似乎总是比传统性能更昂贵。

它与数据绑定有关，假设我有一个用于绑定到我的UI的对象，并且我想根据该对象的其他属性隐藏它。我可以为IsVisible或者Visibility添加扩展属性，然后将该属性绑定到UI。

我们不能绑定扩展方法，但是能够为无法扩展的现有类型添加数据绑定属性可能会非常有用。

在我的书中，扩展属性的第一大原因是围绕未拥有的代码实现流利的接口模式。我围绕NHibernate会话构建了一个包装器，以使其更直观地工作，因此我可以执行类似于

public bool IsInTransaction
{
    get { return _session.Is().Not.Null && _session.Is().InTransaction; }
}

这看起来很愚蠢，因为Is必须是一个方法，因为除非我直接修改会话对象上的源代码，否则我无法将Is作为属性插入。

开发人员应使用属性来组织名称的层次结构，并避免使用驼峰或者下划线来连接名称。
例如，它们应该扩展字符串类以使用诸如" some str"之类的东西，而不是HttpUtility.UrlDecode。
当前在Cis中执行此操作的唯一方法是：" some str" .decode()。url

会有一件好事，但我看到许多人说他们希望将其用于数据绑定，这是不可能的，因为它使用了反射。

是的，请。

并且还添加索引属性和STATIC扩展名，因为我非常希望System.Console拥有该属性(这不是在开玩笑！)。