Почти у каждого программиста есть в загашнике библиотека, которая присутствует в большинстве его проектов. В ней, как правило, содержится некий набор полезняшек, которые упрощают жизнь, но, по каким то причинам, отсутствуют в фреймворке. При этом они слишком малы и мало связаны по теме, чтобы заводить для них отдельные библиотеки.
Проблема в том, что поддержка одному такой библиотеки занимает какое то время, а когда в одном проекте встречается код разных авторов, функционал ее может дублироваться.
CodeJam это проект по сбору таких полезняшек в одну библиотеку, гарантирующую определенный уровень качества и доступную через nuget.
Инфиксные IsNullOrEmpty, IsNullOrWhitespace, NotNullNorEmpty, NotNullNorWhitespace Инфиксный Format Инфиксный Join Length, корректно работающий с null NaturalStringComparer Инфиксные формы для char Дополнительные вариации Substring
Расширения для XDocument
RequiredRoot, RequiredElement, RequiredAttribute ElementValue, AttributeValue (required, optional, alternative names, type conversion etc)
Расширения для рефлекшена
GetAssemblyPath GetRequiredResourceStream GetCustomAttribute<T>/GetCustomAttributes<T>/HasCustomAttribute Enum: GetNames<T>, GetValues<T>, IsDefined<T>, Parse<T>, fast GetFlag Advanced Activator.CreateInstance (required and optional parameters, default values etc) Хелперы с использованием Expression по типу infoof для получения PropertyInfo, FieldInfo, MethodInfo и ConstructorInfo плюс для свойств и полей имена и полное имя (включая всю цепочку: a => a.User.Name вернет "User.Name")
Расширения для коллекций
Concat<T>(T singleElement) AsArray, AsList, AsHashSet ToHashSet Инфиксные формы для Array FirstOrDefault with default value Топологическая сортировка MinItem/MaxItem Array.EqualsTo
Хелпер для сравнения текстовых данных Хелпер для использования ReaderWriterLockSlim совместно с using Хелпер для получения экземпляров пустых массивов без создания объекта каждый раз заново Парсер CSV (experimental) Парсер командной строки (experimental) Ассерты ala Code.NotNull(someValue, "someValue"); Factory для Disposable, using(Disposable.Create(()=>OnDispose())) { } Range<T>/CompositeRange<T> (experimental) Небольшой набор для Func & Action. Часто требуется, например при сортировке создавать делегат, который возвращает сам себя: o => o
Хелпер для дампа куска массива байтов в строку и обратно Option<T> Swap TupleStruct
Компилироваться шестым шарпом будет?
AVK>Расширения для строки
Пригодятся ли такие же инфиксные расширения для Array? Все статические методы этого класса, где первым параметром Array или T[]?
AVK>Расширения для коллекций AVK> * AsArray, AsList, AsHashSet
AsReadOnlyCollection, AsReadOnlyList (по аналогии с Enumerable::AsEnumerable)?
AVK>Расширения для словарей AVK> * GetValueOrDefault
Для какого типа это будет расширением? Если сделать для IDictionary<,> то не будет работать для IReadOnlyDictionary<,> (и vice versa); если сделать для обоих, то компилятор откажется компилировать вызов у Dictionary<,>
AVK>Прочее
Здравствуйте, xy012111, Вы писали:
X>Тут же лучше обсуждать, правильно?
Да.
X>Компилироваться шестым шарпом будет?
Народ склоняется к тому.
AVK>>Расширения для строки X>Пригодятся ли такие же инфиксные расширения для Array? Все статические методы этого класса, где первым параметром Array или T[]?
Если практическая польза есть — почему нет?
X>AsReadOnlyCollection, AsReadOnlyList (по аналогии с Enumerable::AsEnumerable)?
Хм, а в каком сценарии такое может быть? Кто неявно RO коллекции возвращает?
AVK>>Расширения для словарей AVK>> * GetValueOrDefault X>Для какого типа это будет расширением? Если сделать для IDictionary<,> то не будет работать для IReadOnlyDictionary<,> (и vice versa); если сделать для обоих, то компилятор откажется компилировать вызов у Dictionary<,>
Почему не откажется?
AVK>>Прочее X>Memoize я так понял не нужен?
Не знаю. В каком виде он предполагается? Хелпер с лямбдой в параметрах или что?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
X>>AsReadOnlyCollection, AsReadOnlyList (по аналогии с Enumerable::AsEnumerable)? AVK>Хм, а в каком сценарии такое может быть? Кто неявно RO коллекции возвращает?
Когда есть List<string> к примеру или string[], а вернуть нужно KeyValuePair<int, IReadOnlyCollection<string>>. Такой метод кажется лучшим решением, чем тайп-каст.
Кстати, ещё я часто использую тип Pair с расширениями для KeyValuePair самым важным из которых являестя Pair.Create<,>()
AVK>>>Расширения для словарей AVK>>> * GetValueOrDefault X>>Для какого типа это будет расширением? Если сделать для IDictionary<,> то не будет работать для IReadOnlyDictionary<,> (и vice versa); если сделать для обоих, то компилятор откажется компилировать вызов у Dictionary<,> AVK>Почему не откажется?
Не понял. Компилятор как раз откажется.
AVK>>>Прочее X>>Memoize я так понял не нужен? AVK>Не знаю. В каком виде он предполагается? Хелпер с лямбдой в параметрах или что?
Обычно да и с параметрами — какой уровень потокобезопастности нужен, как у Lazy<>
Я там пул-реквест завел с изменениями (косметика + фикс обработки ситуации, когда после "равных" чисел нужно продолжать сранение строк) к NaturalStringComparer и 3-мя вопросами в TODO по нему и методу Args(string format....).
Посмотри, pls.
Здравствуйте, Lexey, Вы писали:
L>Я там пул-реквест завел с изменениями (косметика + фикс обработки ситуации, когда после "равных" чисел нужно продолжать сранение строк) к NaturalStringComparer и 3-мя вопросами в TODO по нему и методу Args(string format....). L>Посмотри, pls.
Посмотрел уже и смержил в мастер.
Касаемо вопросу по компареру — я вообще особо в код не вникал, просто портанул вариант, на который больше всего народ ссылается и убедился что тест проходит. Там Sinix еще на другой вариант ссылку кинул — может там лучше?
Насчет названия для формата — тут ХЗ. В моей либе оно FormatStr называется. Args это IT использует, соотв. оно и в linq2db присуствует. Просто Format, к сожалению, назвать нельзя. Если брать текущую терминологию шарпа, то тогда следует обозвать Interpolate по аналогии со string interpolation.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>CodeJam это проект по сбору таких полезняшек
А почему нет ни слова про зависимости от "JetBrains.Annotations"? Что они делают и почему нельзя без них?
А зачем там сборка подо все мыслимые фрэймворки? Уж если пишешь проект сразу на C#6, то какой смысл собирать под 4.0?
Re[2]: CodeJam - библиотека универсальных полезняшек для .NET
Здравствуйте, Kolesiki, Вы писали:
K>А почему нет ни слова про зависимости от "JetBrains.Annotations"? Что они делают и почему нельзя без них?
Потому что без них можно. Это только для тех у кого решарпер.
K>А зачем там сборка подо все мыслимые фрэймворки? Уж если пишешь проект сразу на C#6, то какой смысл собирать под 4.0?
Проект хоть и на C#6, но может использоваться из C#4+.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
1)
public static IEnumerable<T> Prepend<T>(this IEnumerable<T> source, T element)
public static IEnumerable<T> Concat<T>(this IEnumerable<T> source, T element)
Почему Concat ?? ИМХО логичнее было бы Append.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Jack128, Вы писали:
J>>Почему Concat ?? ИМХО логичнее было бы Append.
AVK>Потому что Enumerable.Concat уже есть.
Ну так четко же написано: >> Разный набор методов типа AsArray, AsList, AsHashSet, помогает избежать ненужной конвертации IEnumerable<T>, если на вход подали объект соответствующего типа
где в текущей реализации избежали тайпкаст — не видно..
J>>Может имелось в виду что нить типа такого AsArray<T>(this IEnumerable<T> source) => (source as T[]) ?? source.ToArray() ?
AVK>Вряд ли. Enumerable.AsEnumerable видел в Fx? Знаешь зачем он нужен?
Чтоб сделать upcast от IQueryable к IEnumerable.
Встречный вопрос: ты много встречал наследников массива??
более того, для юзкейса AsEnumerable критично, что у IQueryable и IEnumerable есть одноименные, совместимые по сигнатуре методы. Нету всех этих условий ни у List'а, ни у массива, ни у HashSet'а.
Кстати, в NET'е есть метод AsQueryable(), его вообще хоть раз кто нить использовал? вот он столь же бесполезен, как и AsList
Re[4]: CodeJam - библиотека универсальных полезняшек для .NET
Здравствуйте, Jack128, Вы писали:
AVK>>Потому что Enumerable.Concat уже есть. J>Эт я понимаю, но вот честно, если б меня спросили: J>"есть метод, который добавляем элемент в начало последовательности, он называется Prepend. Как называется метод который добавляет элемент в конец последовательности?" J>я б вряд ли сказал Concat.
А если бы спросили как называется метод, который упрощает синтаксис метода Concat?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Насчет названия для формата — тут ХЗ. В моей либе оно FormatStr называется. Args это IT использует, соотв. оно и в linq2db присуствует. Просто Format, к сожалению, назвать нельзя. Если брать текущую терминологию шарпа, то тогда следует обозвать Interpolate по аналогии со string interpolation.
Видел еще вариант FormatWith
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[2]: CodeJam - библиотека универсальных полезняшек для .NET
Кстати, как заставить решарпер применять локальные настройки проекта? Раньше проблем не замечал, а сейчас что ни делаю, все равно пробелы вместо табов вставляет
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[3]: CodeJam - библиотека универсальных полезняшек для .NET
Здравствуйте, rameel, Вы писали:
R>Кстати, как заставить решарпер применять локальные настройки проекта? Раньше проблем не замечал, а сейчас что ни делаю, все равно пробелы вместо табов вставляет
Пробелы — никак, решарпер ими не управляет, это студийная неотключаемая настройка. Возможно упомянутый тут editconfig спасет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Отступы — табуляция. Рекомендуется так же включать visible whitespaces и не оставлять в коде пробельный мусор.
Имена типов и публичных членов — PascalCasing
Имена приватных членов — camelCasing с префиксом '_'
Имена параметров и локальных переменных — camelCasing
Максимальная длина строк — 120 символов.
Дополнительные требования к коду
Обязательно наличие doc comments к публичному API
Для любого нетривиального кода должны быть тесты хотя бы по основным use cases
Желательно использование решарпера и разметка кода Jetbrains.Annotations. Прежде всего это касается NotNull/CanBeNull.
Cтарайтесь максимально использовать конструкции языка, улучшающие читаемость кода: var, expression bodied members, string interpolation
Обязательно никаких warnings компилятора, и очень желательно никаких warnings решарпера. Если у вас нет лицензии на решарпер — используйте хотя бы бесплатные Resharper Command Line Tools.
В Main проект помещайте только тот код, в полезности которого вы абсолютно уверены.
Здравствуйте, xy012111, Вы писали:
X>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства? X>Поля это всё ж некоторые инструменты (детали) реализации, а в интерфейсе самое место свойствам.
Честно говоря не вижу никакой существенной разницы между readonly полем и свойством.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Тогда имя надо другое. As вводит в заблуждение. R>>Можно, а какое? AVK>ХЗ. ToArray занято. MakeArray, CastToArray?
Чего вы мучаетесь? AsArray, AsList используется уже в куче проектов, которые я видел. Никаких проблем. Вообще.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
X>>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства? X>>Поля это всё ж некоторые инструменты (детали) реализации, а в интерфейсе самое место свойствам.
AVK>Честно говоря не вижу никакой существенной разницы между readonly полем и свойством.
Здравствуйте, xy012111, Вы писали:
X>>>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства? X>Как минимум тут, Field Design, первый же пункт:
FDG надо читать, а не просто цитировать.
DO NOT provide instance fields that are public or protected.
Причём читать медленно и методично, ибо воды в ней нет совсем и плотность информации на страницу откровенно зашкаливает. И, главное, читать до конца:
DO use public static readonly fields for predefined object instances.
If there are predefined instances of the type, declare them as public readonly static fields of the type itself.
... DO NOT assign instances of mutable types to readonly fields.
Здравствуйте, Sinix, Вы писали:
X>>>>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства? X>>Как минимум тут, Field Design, первый же пункт:
S>FDG надо читать, а не просто цитировать.
Избавьте. Не читать нужно, а понимать. И не только смысл, но и причины.
Вы, видимо, даже смысл не совсем поняли и на вопрос "почему скобочки вокруг статических" ответить не смогли бы. А, наприммер, вот почему.
Вообще, и статические поля совсем не нужны, тем более когда есть возможность инициализации свойста при объявлении. Не верите? Какой-нибудь EqualityComparer<>.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.
Требование же о неизменячемости типа readonly полей совершенно бредово: его выполнение приводит к запрету
Здравствуйте, xy012111, Вы писали: X>Вы, видимо, даже смысл не совсем поняли и на вопрос "почему скобочки вокруг статических" ответить не смогли бы. А, наприммер, вот почему.
Вот тут всё правильно — публичных readonly полей у инстансов быть не должно. Причина бага — код в experimental, там за рекомендациями никто особо не следит. Автору напишите
X>Вообще, и статические поля совсем не нужны, тем более когда есть возможность инициализации свойста при объявлении. Не верите? Какой-нибудь EqualityComparer<>.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.
Неправильно. Потому что public static readonly field даёт кучу гарантий, которое от свойств не получить никак. Чтоб не углубляться: достаточно гарантированно рабочего ReferenceEquals + оптимизаций jit
Здравствуйте, xy012111, Вы писали:
X>Вообще, и статические поля совсем не нужны
Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
X>>Вообще, и статические поля совсем не нужны
AVK>Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись.
С чего вы взяли, что я выставлял её как истину в последней инстанции?
Я лишь привёл пример точки зрения, которая делает различие между одним и другим. Вы же не категорически высказались против, не привели никакой причины, а лишь сказали, что не видите существенной разницы. Ну если вы не видите, то я показал, что видят, как минимум, другие. Чего тут не понятного? Дело хозхяйское, куда смотреть и смотреть ли вообще и что считать существенным.
/* Вот NRE из CodeJam пользователь может огрести из ста тыщ пятиста мест, если для вас это не существенно, если такая забота об аргументах, по вашему мнению, должна делаться клиентом, ваше право ;о) Но и тут многие с вами не согласятся */
Вот если не сочтёте за труд посмотреть на BCL, то сможете заметить, что мест, где наружу торчат экземплярные поля раз-два и обчёлся. Я вот даже и не припомню ни одного.
Относительно статических полей немного другая картина: кой-где, даже много где, они торчат. Но или со времён ещё первого дотнета, когда ни о каких гайдлайнах не слышали и, быть может, вовсе не задумывались о каком-то дизайне, или по другим причинам. Скорее всего, просто из-за невозможноси проинициализировать свойство при объявлении. Разносить инициализацию и объявление, при необходимости объявлять, к примеру, десятки DependencyProperty и ключей к ним действительно проблема.
Но некоторые хорошие люди (в BCL) и тут не ленятся делать более правильные во всех отношениях свойства, пример я привёл и их ещё не мало, а уж в шестом шарпе вообще ничто не должно останавливать.
Я для себя это объясняю просто — поле это нечто "физическое", "способ реализации" который не здорово выставлять наружу. А вот свойство — это некий контракт. Извне, пользователям типа, не важен способ реализации, необходим только контракт. Так и не нужно им пихать поле когда достаточно дать свойство.
Здравствуйте, xy012111, Вы писали:
AVK>>Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись. X>С чего вы взяли, что я выставлял её как истину в последней инстанции?
Ну ты же, вместо того чтобы самому ответить на простой вопрос — зачем делать поля свойствами — привел ссылку на FDG. Мол, раз там написано, то надо не рефлексировать, а исполнять.
X>Я лишь привёл пример точки зрения, которая делает различие между одним и другим.
Понимаешь какое дело, чем с точки зрения дизайна отличаются поля и своййства экземпляра я понимаю — поля не являются частью формального контракта типа и их нельзя вынести в базовый класс или интерфейс. А вот чем не угодили статические поля — я пока ответа не видел, одни эмоции: бредово, ересь, для дураков.
X> Вы же не категорически высказались против, не привели никакой причины, а лишь сказали, что не видите существенной разницы. Ну если вы не видите, то я показал, что видят, как минимум, другие.
Ну мало ли кто что видит. Некоторые рептилоидов с Нибиру видят. Мне интересны не видения, а логическое обоснование. Мой опыт пока не выявил каких то недостатков static readonly полей.
X>Вот если не сочтёте за труд посмотреть на BCL, то сможете заметить, что мест, где наружу торчат экземплярные поля раз-два и обчёлся.
Да и в CodeJam из совсем немного. И ровно 100% их укладываются в:
DO use public static readonly fields for predefined object instances.
X> Я вот даже и не припомню ни одного.
Ну ты не припомнишь, я припомню. Мы сейчас что обсуждаем — память?
X>Относительно статических полей немного другая картина:
А ты сейчас про какие? В CodeJam есть публичные нестатические поля? Таких полей там ровно в одном месте в экспериментальной части.
X>Но или со времён ещё первого дотнета, когда ни о каких гайдлайнах не слышали и, быть может, вовсе не задумывались о каком-то дизайне, или по другим причинам.
Какой прекрасный аргумент. Подходит практически к любой ситуации.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись. X>>С чего вы взяли, что я выставлял её как истину в последней инстанции? AVK>Ну ты же, вместо того чтобы самому ответить на простой вопрос — зачем делать поля свойствами — привел ссылку на FDG. Мол, раз там написано, то надо не рефлексировать, а исполнять.
Ну то есть сами придумали, чего не было написано, а виноват я?
X>>Я лишь привёл пример точки зрения, которая делает различие между одним и другим. AVK>Понимаешь какое дело, чем с точки зрения дизайна отличаются поля и своййства экземпляра я понимаю — поля не являются частью формального контракта типа и их нельзя вынести в базовый класс или интерфейс. А вот чем не угодили статические поля — я пока ответа не видел, одни эмоции: бредово, ересь, для дураков.
Я написал же. Есть такое понятие "статический интерфейс" в смысле "интерфейс" — это то, с помощью чего клиент работает с типом, а не interface. И мне гораздо проще считать, что наружу торчат свойства, чем в случае экземпляра наружу в основном свойства или в эксперементал может быть и поля, а в случае статики — только поля ну или свойства если так захотелось. "Всегда наружу свойства" проще и понятнее, тем более, если технически разницы нет :о) Это основной поинт.
X>> Вы же не категорически высказались против, не привели никакой причины, а лишь сказали, что не видите существенной разницы. Ну если вы не видите, то я показал, что видят, как минимум, другие. AVK>Ну мало ли кто что видит. Некоторые рептилоидов с Нибиру видят. Мне интересны не видения, а логическое обоснование. Мой опыт пока не выявил каких то недостатков static readonly полей.
Спасибо, это была очень важная реплика в таком техническом вопросе. Причем я пытиался с помощью отвлечения описать предмет спора, а вы — мой комментерий. Продолжайте дальше в таком виде вести дискуссию и люди к вам, несомненно, понятянуся.
X>>Вот если не сочтёте за труд посмотреть на BCL, то сможете заметить, что мест, где наружу торчат экземплярные поля раз-два и обчёлся. AVK>Да и в CodeJam из совсем немного. И ровно 100% их укладываются в:
AVK>DO use public static readonly fields for predefined object instances.
Ну я не знал, что в эксперементальной части у вас другие гайдлайны. Мне такой подход ещё более не понятен. Мне понятен подход бармена из анекдота про нежеление сбивать руку. А ваш — нет.
X>> Я вот даже и не припомню ни одного. AVK>Ну ты не припомнишь, я припомню. Мы сейчас что обсуждаем — память?
Ну и могли бы хоть один привести А обсуждаем мы другое, общеупотребильность этого подхода. Если в BCL так (в основном) не делают, только в некоторых местах, разработчики которых почему-то специально так решили или просто не подумали, то может и тут не стоит? И на всякий случай я там имел в виду именно публичные экземплярные поля.
X>>Относительно статических полей немного другая картина: AVK>А ты сейчас про какие? В CodeJam есть публичные нестатические поля? Таких полей там ровно в одном месте в экспериментальной части.
Мне, когда смотрел код, достаочно было увидеть в одном месте, что бы озадачиться. Надо было всё перечитать прежде чем написать?
X>>Но или со времён ещё первого дотнета, когда ни о каких гайдлайнах не слышали и, быть может, вовсе не задумывались о каком-то дизайне, или по другим причинам. AVK>Какой прекрасный аргумент. Подходит практически к любой ситуации.
Вам поспорить, или разобраться?
Если второе, то лучший способ — сравнить самому код Comparer(of T) и Comparer.
Если не очевидно,
2all: сорри за спойлер
Создание Comparer<T> включает в себя эмит кода для генерик-класса и должно выполняться лениво, не блокируя другие потоки.
В случае с полем инициализация выполнялась бы при первом обращении к самому типу (точнее, не позже чем, там beforefieldinit емнип) и завешивала бы все потоки, пытающиеся обратиться к этому типу, включая наследников Comparer<T>.
Если вам интересно — вы во-первых спрашивайте вопросы нормально, не изображая владельца тайного знания, а во-вторых — в профильном разделе. Всегда вэлкам
Здравствуйте, Sinix, Вы писали:
X>>Если нужна пища для размышления, сравните Comparer.Default Field и Comparer<T>.Default Property. Почему в старой ламповой версии так, а в более современной сяк?
S>Вам поспорить, или разобраться?
Спилите мушку.
S>Если второе, то лучший способ — сравнить самому код Comparer(of T) и Comparer.
Ну наконец-то! Теперь представьте ситуёвину: у вас торчит наружу открытое статическое поле, а в новой версии библиотеки вы вдруг понимаете, что сделав ленивое вычисление значения, присваевоемого этому полю, вы можете что-то улучшить в возвращаемом значении. И приходится либо терять совместимость либо пристраивать костыли. А свойство рррраз! И всё. В любой момент внутренности можно как угодно допилить.
А вот обратного примера, когда потребовалась бы замена свойства на поле я не знаю. Поэтому наружу только свойства. Это проще запоминать, всегда можно до-пере-пилить. Ни одного преимущества у полей нет. У свойств они, пускай, не очевидны и не всегда нужны, но всё же есть.
S>Если вам интересно — вы во-первых спрашивайте вопросы нормально, не изображая владельца тайного знания, а во-вторых — в профильном разделе. Всегда вэлкам
Здравствуйте, xy012111, Вы писали:
X>Ну наконец-то! Теперь представьте ситуёвину: у вас торчит наружу открытое статическое поле, а в новой версии библиотеки вы вдруг понимаете, что сделав ленивое вычисление значения, присваевоемого этому полю, вы можете что-то улучшить в возвращаемом значении.
Просто прочтите наконец 5.5 Field design, главка на страницу. Там даже пример, что такое "predefined object instance" есть. И сразу ниже этого абзаца — рекомендация на случай, если значение будет меняться.
А то ваши возражения пока выглядят вот так вот: матчасть не читал, но мнение имею.
Без обид
X>А вот обратного примера, когда потребовалась бы замена свойства на поле я не знаю.
Огосспидя, вы когда начинаете спорить — забрало не опускайте
Ответы вам пишут не для переспорить, а подкинуть информацию для размышлений. Сценарии, когда свойство не заменит поле, я приводил выше.
Здравствуйте, xy012111, Вы писали:
X>Ну то есть сами придумали, чего не было написано, а виноват я?
Что значит придумали? Поясни тогда, почему ты в ответ на просьбу обосновать привел ссылку на FDG? Зачем ты это сделал?
X>Я написал же.
Ты написал только свои ощущения. Ну я понял, что тебе не нравится. А что нибудь объективное есть?
X> Есть такое понятие "статический интерфейс" в смысле "интерфейс" — это то, с помощью чего клиент работает с типом, а не interface.
Понятие то есть, но какой в нем, в контексте дотнета, смысл? И почему в него не входят публичные поля?
X> И мне гораздо проще считать, что наружу торчат свойства, чем в случае экземпляра
Давай все таки обсуждение экземплярных полей вынесем за рамки.
X>а в случае статики — только поля ну или свойства если так захотелось. "Всегда наружу свойства" проще и понятнее
Ну вот лично мне — нет, не проще. Никакой практически заметной разницы между статическими полями и статическими свойствами я пока не обнаружил. Если эта разница есть, причем не на уровне нравится/не нравится, а объективно — с удовольствием послушаю.
X>, тем более, если технически разницы нет :о)
Я бы не был на 100% уверен. Работа дотнетного оптимизатора — дело темное. Тут вон совсем недавно в CodeJam AgressiveInlining добавляли, хотя, казалось бы, разницы быть не должно.
AVK>>Да и в CodeJam из совсем немного. И ровно 100% их укладываются в: X>
AVK>>DO use public static readonly fields for predefined object instances.
X>Ну я не знал, что в эксперементальной части у вас другие гайдлайны.
Экспериментальная часть потому и экспериментальная, что код там не доведен до production состояния. А гайдлайны там те же.
X>Ну и могли бы хоть один привести А обсуждаем мы другое, общеупотребильность этого подхода. Если в BCL так (в основном) не делают,
В BCL именно так и делают. К примеру:
public static readonly DateTime MinValue
X> только в некоторых местах, разработчики которых почему-то специально так решили или просто не подумали, то может и тут не стоит?
Я вот тебе просто рекомендую — не стоит "не подумали" считать объяснением тех или иных решений в фреймворке. Не, там есть конечно и косяки, но их очень очень мало. И уж точно то что написано в FDG прямым текстом "не подумали" считать не следует.
X> И на всякий случай я там имел в виду именно публичные экземплярные поля.
Мне еще сколько раз надо написать про экземплярные поля чтобы ты уже про них не поминал?
AVK>>А ты сейчас про какие? В CodeJam есть публичные нестатические поля? Таких полей там ровно в одном месте в экспериментальной части. X>Мне, когда смотрел код, достаочно было увидеть в одном месте, что бы озадачиться. Надо было всё перечитать прежде чем написать?
Если сделать для IDictionary<,> то не будет работать для IReadOnlyDictionary<,> (и vice versa); если сделать для обоих, то компилятор откажется компилировать вызов у Dictionary<,>
Если нам не помогут, то мы тоже никого не пощадим.
