Информация об изменениях

Сообщение Re[6]: Информация для разработчиков библиотеки от 07.04.2016 9:51

Изменено 07.04.2016 12:46 Sinix

Здравствуйте, xy012111, Вы писали:
X>Вы, видимо, даже смысл не совсем поняли и на вопрос "почему скобочки вокруг статических" ответить не смогли бы. А, наприммер, вот почему.

Вот тут всё правильно — публичных readonly полей у инстансов быть не должно. Причина бага — код в experimental, там за рекомендациями никто особо не следит. Автору напишите


X>Вообще, и статические поля совсем не нужны, тем более когда есть возможность инициализации свойста при объявлении. Не верите? Какой-нибудь EqualityComparer<>.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.


Неправильно. Потому что public static readonly field даёт кучу гарантий, которое от свойств не получить никак. Чтоб не углубляться: достаточно гарантированно рабочего ReferenceEquals + оптимизаций jit
Автор: Sinix
Дата: 27.03.16
.


X>Требование же о неизменячемости типа readonly полей совершенно бредово: его выполнение приводит к запрету

private readonly List<int> values…
private readonly ObjectPool<чего-то там> pool…

И вот тут неправильно. Прочитайте наконец книжку целиком, а то вы со своими толкованиями FDG каждый раз ещё больше подставляетесь.

[q]
lt is worth noting that this book focuses on design issues that directly affect the programmability of a framework (publicly accessible APIs1).

1. This includes public types, and their public, protected, and explicitly implemented members
of these types.

Почему рекомендация про public mutable readonly поля правильная — см сюда.

Ещё вопросы?
Re[6]: Информация для разработчиков библиотеки
Здравствуйте, xy012111, Вы писали:
X>Вы, видимо, даже смысл не совсем поняли и на вопрос "почему скобочки вокруг статических" ответить не смогли бы. А, наприммер, вот почему.

Вот тут всё правильно — публичных readonly полей у инстансов быть не должно. Причина бага — код в experimental, там за рекомендациями никто особо не следит. Автору напишите


X>Вообще, и статические поля совсем не нужны, тем более когда есть возможность инициализации свойста при объявлении. Не верите? Какой-нибудь EqualityComparer&lt;&gt;.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.


Неправильно. Потому что public static readonly field даёт кучу гарантий, которое от свойств не получить никак. Чтоб не углубляться: достаточно гарантированно рабочего ReferenceEquals + оптимизаций jit
Автор: Sinix
Дата: 27.03.16
.


X>Требование же о неизменячемости типа readonly полей совершенно бредово: его выполнение приводит к запрету

private readonly List<int> values…
private readonly ObjectPool<чего-то там> pool…

И вот тут неправильно. Прочитайте наконец книжку целиком, а то вы со своими толкованиями FDG каждый раз ещё больше подставляетесь.

lt is worth noting that this book focuses on design issues that directly affect the programmability of a framework (publicly accessible APIs1).

1. This includes public types, and their public, protected, and explicitly implemented members
of these types.


Почему рекомендация про public mutable readonly поля правильная — см сюда.

Ещё вопросы?