Сообщение 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
X>Требование же о неизменячемости типа readonly полей совершенно бредово: его выполнение приводит к запрету
И вот тут неправильно. Прочитайте наконец книжку целиком, а то вы со своими толкованиями 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 поля правильная — см сюда.
Ещё вопросы?
X>Вы, видимо, даже смысл не совсем поняли и на вопрос "почему скобочки вокруг статических" ответить не смогли бы. А, наприммер, вот почему.
Вот тут всё правильно — публичных readonly полей у инстансов быть не должно. Причина бага — код в experimental, там за рекомендациями никто особо не следит. Автору напишите
X>Вообще, и статические поля совсем не нужны, тем более когда есть возможность инициализации свойста при объявлении. Не верите? Какой-нибудь EqualityComparer<>.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.
Неправильно. Потому что public static readonly field даёт кучу гарантий, которое от свойств не получить никак. Чтоб не углубляться: достаточно гарантированно рабочего ReferenceEquals + оптимизаций jit
Автор: Sinix
Дата: 27.03.16
.Дата: 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<>.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.
Неправильно. Потому что public static readonly field даёт кучу гарантий, которое от свойств не получить никак. Чтоб не углубляться: достаточно гарантированно рабочего ReferenceEquals + оптимизаций jit
X>Требование же о неизменячемости типа readonly полей совершенно бредово: его выполнение приводит к запрету
И вот тут неправильно. Прочитайте наконец книжку целиком, а то вы со своими толкованиями FDG каждый раз ещё больше подставляетесь.
Почему рекомендация про public mutable readonly поля правильная — см сюда.
Ещё вопросы?
X>Вы, видимо, даже смысл не совсем поняли и на вопрос "почему скобочки вокруг статических" ответить не смогли бы. А, наприммер, вот почему.
Вот тут всё правильно — публичных readonly полей у инстансов быть не должно. Причина бага — код в experimental, там за рекомендациями никто особо не следит. Автору напишите
X>Вообще, и статические поля совсем не нужны, тем более когда есть возможность инициализации свойста при объявлении. Не верите? Какой-нибудь EqualityComparer<>.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.
Неправильно. Потому что public static readonly field даёт кучу гарантий, которое от свойств не получить никак. Чтоб не углубляться: достаточно гарантированно рабочего ReferenceEquals + оптимизаций jit
Автор: Sinix
Дата: 27.03.16
.Дата: 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 поля правильная — см сюда.
Ещё вопросы?