Следует ли добавлять свойства расширения в C# 4.0?

Поскольку свойства - это просто синтаксический сахар для методов, я не понимаю, почему в C# должны быть методы расширения без свойств расширения.

Не знаю почему. Свойства - это просто методы получения / установки с другим синтаксисом.

Я думаю, это было бы здорово, если бы при их использовании не было потери производительности или было бы минимальным.

Определенно добавлю к репертуару инструментов, имеющихся в нашем распоряжении.

Что касается моего мнения, да, они должны, но, как и все, разработчикам нужно использовать это правильно и при необходимости. Как и большинство новых функций, многие разработчики используют их, не понимая их полностью и не понимая, когда / как / где / как лучше всего их использовать. Я знаю, что меня тоже иногда втягивает в это.

Но я, конечно, принеси это. Я видел, как использую его в определенных сценариях

Я предполагаю, что проиндексированные свойства будут всего лишь набором значительных улучшений, которые мы увидим в 4.0.

Я не думаю, что свойства расширения были бы столь же полезны. Я обнаружил, что в основном использую свойства для инкапсуляции полей (классический get; set;) или для обеспечения качества только для чтения (просто get в закрытом, только для чтения, поле набора конструкторов). Поскольку расширения не могут получить доступ к закрытым членам, я не вижу в этом смысла, особенно для "set;". Чтобы сделать что-нибудь, «установить»; в любом случае придется вызывать другие методы. Затем вы сталкиваетесь с проблемой, когда свойства генерируют исключения.
Поскольку расширения ограничиваются использованием общедоступных свойств и методов, я считаю, что код, использующий служебный класс, чище и легче читается. Когда дело доходит до этого, мы используем методы расширения, чтобы LINQ выглядел красиво. Чтобы разработчики не поступали неправильно, я могу иметь дело с extra () здесь и там в моем 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 метода.

Похоже, им легко воспользоваться не по назначению. Как уже упоминалось, свойства C# - это просто синтаксический сахар для методов. Однако реализация их в качестве свойств имеет определенные коннотации: доступ не будет иметь побочных эффектов, а изменение свойства должно быть очень недорогим. Последний момент имеет решающее значение, поскольку кажется, что свойства расширения почти всегда будут дороже, чем обычные свойства.

Речь идет о привязке данных, допустим, у меня есть объект для привязки к моему пользовательскому интерфейсу, и я хочу скрыть, чтобы он отображался на основе других свойств объекта. Я мог бы добавить свойство расширения для IsVisible или Visibility и привязать это свойство к пользовательскому интерфейсу.

Вы не можете связывать методы расширения, но возможность добавлять свойства для привязки данных к существующим типам, которые вы не можете расширить, может быть очень полезной.

В моей книге № 1 наиболее существенной причиной для свойств расширения является реализация гибких шаблонов интерфейса для кода, не принадлежащего владельцу. Я создал оболочку вокруг сеанса NHibernate, чтобы сделать его более интуитивно понятным для работы, чтобы я мог выполнять логику, аналогичную

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

Что выглядит очень глупо, что Is должен быть методом, поскольку у меня нет возможности вставить Is как свойство, если я напрямую не изменю источник в объекте сеанса.

Разработчикам следует использовать свойства для организации иерархии имен и избегать объединения имен с использованием верблюжьего регистра или подчеркивания. Например, вместо HttpUtility.UrlDecode они должны расширить строковый класс, чтобы использовать что-то вроде "some str" .decode.url В настоящее время единственный способ сделать это в C# - это: "some str" .decode (). Url

Было бы неплохо иметь, но я вижу, что многие люди говорят, что они хотят, чтобы это было для привязки данных, что невозможно, поскольку оно использует отражение.

Да, пожалуйста.

А также добавьте проиндексированные свойства и статические расширения, потому что я СЕРЬЕЗНО хочу этого для System.Console (это не шутка!).