是否应将扩展属性添加到C＃4.0？
我希望这能用于流畅的界面。 例如，参见Channel9讨论。 可能还需要添加索引属性。
你的想法是什么？ 优势会超过“语言混乱”吗？
在我的书中，扩展属性的第一个最重要的原因是围绕无主代码实现流畅的接口模式。 我在NHibernate会话周围构建了一个包装器，使其更具有本构性，因此我可以做类似的逻辑
public bool IsInTransaction { get { return _session.Is().Not.Null && _session.Is().InTransaction; } } 这看起来非常愚蠢是必须是一个方法，因为除非我直接修改会话对象上的源，否则我无法将Is作为属性插入。
由于属性只是方法的语法糖，我不明白为什么C＃应该有没有扩展属性的扩展方法。
这是关于数据绑定，假设我有一个绑定到我的UI的对象，我想隐藏基于对象的其他属性显示它。 我可以为IsVisible或Visibility添加扩展属性，并将该属性绑定到UI。
您无法绑定扩展方法，但能够将数据绑定的属性添加到您无法扩展的现有类型可能非常有用。
我不知道为什么不。 属性只是具有不同语法的getter / setter方法。
我不认为扩展属性几乎是有用的。 我发现自己主要使用属性来封装字段（经典get; set;）或提供只读的优点（只需获取私有，只读，构造函数集字段）。 由于扩展无法访问私有成员，我真的没有看到这一点，特别是对于“set;”。 要做任何事情，“设置;” 无论如何都只需要调用其他方法。 然后你会遇到抛出exception的属性问题。
由于扩展仅限于使用公共属性和方法，因此我发现使用实用程序类的代码更清晰，更容易。 归结为它，我们使用扩展方法使LINQ看起来很漂亮。 为了防止开发人员做错事，我可以在LINQ中处理一个额外的（）并坚持使用扩展方法。
我想这会很棒，只要在使用它们时没有或只有最小的性能损失。
好像它很容易被滥用。 正如其他人所提到的，C＃属性只是方法的语法糖。 但是，将它们作为属性实现具有某些含义：访问不会产生副作用，修改属性应该非常便宜。 后一点至关重要，因为看起来扩展属性几乎总是比传统属性更昂贵。
这将是一件好事，但我看到许多人说他们想要数据绑定，这是不可能的，因为它使用reflection。
肯定会添加到我们可以使用的工具库中。
现在，就我而言，是的，他们应该，但就像任何事情一样，开发人员需要在需要时正确使用它。 像大多数新function一样，很多开发人员在没有完全理解它们以及何时/如何/在何处/如何最好地使用它们的情况下使用它们。 我知道我有时也会陷入困境。
但是，当然，请带上它。 我可以看到自己在某些情况下使用它
我猜测索引属性将仅仅是我们将在4.0中看到的一大堆重要增强中的一个放养填充物。
开发人员应使用属性来组织名称层次结构，并避免使用驼峰套管或下划线进行名称连接。 例如，代替HttpUtility.UrlDecode，他们应该扩展字符串类以使用类似“some str”.decode.url的东西目前在C＃中执行它的唯一方法是：“some str”.decode（）。url
是的，请。
并且还添加索引属性和STATIC扩展名，因为我非常想要System.Console（这不是一个笑话！）。
不，属性只是隐藏代码生成内容的一种方法。 如果您查看反映的代码或IL，您可以确定您真正得到的内容，它是以下内容：
public string MyProperty { get; set; }
变
public string get_MyProperty(){ return ; } public string set_MyProperty(string value) { = value; }
这只是两种方法。