CodeJam - библиотека универсальных полезняшек для .NET
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.16 20:02
Оценка: 2 (1) +2
#Имя: wiki.prj.codejam
Почти у каждого программиста есть в загашнике библиотека, которая присутствует в большинстве его проектов. В ней, как правило, содержится некий набор полезняшек, которые упрощают жизнь, но, по каким то причинам, отсутствуют в фреймворке. При этом они слишком малы и мало связаны по теме, чтобы заводить для них отдельные библиотеки.
Проблема в том, что поддержка одному такой библиотеки занимает какое то время, а когда в одном проекте встречается код разных авторов, функционал ее может дублироваться.
CodeJam это проект по сбору таких полезняшек в одну библиотеку, гарантирующую определенный уровень качества и доступную через nuget.

Исходные коды
Серверные сборки
Первоначальное обсуждение идеи
Автор: AndrewVK
Дата: 15.03.16

CodeJam Roadmap
Nuget-фид с пакетами из ночных сборок
Информация для разработчиков библиотеки
Сгенерированная документация
AVK Blog
Отредактировано 22.03.2016 13:04 AndrewVK . Предыдущая версия . Еще …
Отредактировано 19.03.2016 13:05 AndrewVK (devinfo link) . Предыдущая версия .
Отредактировано 18.03.2016 11:07 AndrewVK . Предыдущая версия .
Отредактировано 17.03.2016 12:48 AndrewVK (Links) . Предыдущая версия .
Отредактировано 16.03.2016 20:40 AndrewVK (Roadmap link) . Предыдущая версия .
Отредактировано 16.03.2016 20:03 AndrewVK . Предыдущая версия .
Информация для разработчиков библиотеки
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.03.16 13:03
Оценка: 44 (2)
#Имя: wiki.codejam.devinfo

Стиль кода

Стиль кодирования

Коротко (с поправками):


Дополнительные требования к коду

AVK Blog
Отредактировано 19.03.2016 13:04 AndrewVK (Make wiki) . Предыдущая версия .
Re[4]: Информация для разработчиков библиотеки
От: Sinix  
Дата: 07.04.16 07:28
Оценка: +1 -1
Здравствуйте, 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.

Разобрались?
Re[6]: Информация для разработчиков библиотеки
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.04.16 09:59
Оценка: +1 :)
Здравствуйте, xy012111, Вы писали:

X>Вообще, и статические поля совсем не нужны


Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[8]: Информация для разработчиков библиотеки
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 07.04.16 10:38
Оценка: +2
Здравствуйте, 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>>
AVK Blog
CodeJam Roadmap
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.16 20:39
Оценка: +1
#Имя: wiki.codejam.roadmap

Расширения для строки

  • Инфиксные 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

    Расширения для словарей

  • GetOrAdd, AddOrUpdate
  • GetValueOrDefault
  • KeyEqualityComparer

    Кеши, пулы

  • Словарь с ленивой инициализацией элементов, желательно потокобезопасный
  • ObjectPool
  • Memoize

    Расширения для IO

  • TempDir/TempFile/TempStream returns IDisposable

    Алгоритмы

  • lower_bound
  • upper_bound
  • equal_range
  • partition_point

    Прочее

  • Хелпер для сравнения текстовых данных
  • Хелпер для использования 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 Blog
    Отредактировано 01.04.2016 14:24 AndrewVK . Предыдущая версия . Еще …
    Отредактировано 28.03.2016 0:47 AndrewVK . Предыдущая версия .
    Отредактировано 27.03.2016 1:50 AndrewVK . Предыдущая версия .
    Отредактировано 27.03.2016 1:49 AndrewVK . Предыдущая версия .
    Отредактировано 24.03.2016 18:00 AndrewVK . Предыдущая версия .
    Отредактировано 23.03.2016 21:22 AndrewVK . Предыдущая версия .
    Отредактировано 23.03.2016 16:53 AndrewVK . Предыдущая версия .
    Отредактировано 23.03.2016 11:51 Lexey . Предыдущая версия .
    Отредактировано 22.03.2016 23:52 AndrewVK . Предыдущая версия .
    Отредактировано 21.03.2016 23:06 AndrewVK . Предыдущая версия .
    Отредактировано 21.03.2016 0:19 AndrewVK . Предыдущая версия .
    Отредактировано 20.03.2016 23:26 AndrewVK . Предыдущая версия .
    Отредактировано 19.03.2016 22:42 AndrewVK . Предыдущая версия .
    Отредактировано 18.03.2016 23:03 AndrewVK . Предыдущая версия .
    Отредактировано 18.03.2016 21:42 AndrewVK . Предыдущая версия .
    Отредактировано 18.03.2016 21:19 AndrewVK . Предыдущая версия .
    Отредактировано 18.03.2016 19:39 AndrewVK . Предыдущая версия .
    Отредактировано 18.03.2016 0:45 AndrewVK (New feature) . Предыдущая версия .
    Отредактировано 18.03.2016 0:37 AndrewVK (Mark implemented) . Предыдущая версия .
    Отредактировано 18.03.2016 0:06 AndrewVK (Mark implemented) . Предыдущая версия .
    Отредактировано 17.03.2016 22:58 AndrewVK (New features) . Предыдущая версия .
    Отредактировано 17.03.2016 19:41 AndrewVK (Mark implemented) . Предыдущая версия .
    Отредактировано 17.03.2016 12:25 AndrewVK (Mark implemented) . Предыдущая версия .
    Отредактировано 16.03.2016 23:16 AndrewVK (Formatting) . Предыдущая версия .
    Отредактировано 16.03.2016 23:15 AndrewVK (Add TempXXX) . Предыдущая версия .
    Отредактировано 16.03.2016 20:58 AndrewVK (Add some) . Предыдущая версия .
    Отредактировано 16.03.2016 20:42 AndrewVK . Предыдущая версия .
    Отредактировано 16.03.2016 20:39 AndrewVK (Make wiki) . Предыдущая версия .
    Re: CodeJam - библиотека универсальных полезняшек для .NET
    От: Kolesiki  
    Дата: 17.03.16 22:41
    Оценка: +1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>CodeJam это проект по сбору таких полезняшек


    А почему нет ни слова про зависимости от "JetBrains.Annotations"? Что они делают и почему нельзя без них?
    А зачем там сборка подо все мыслимые фрэймворки? Уж если пишешь проект сразу на C#6, то какой смысл собирать под 4.0?
    Re: Информация для разработчиков библиотеки
    От: xy012111  
    Дата: 19.03.16 19:44
    Оценка: +1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Стиль кода


    Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства?

    Поля это всё ж некоторые инструменты (детали) реализации, а в интерфейсе самое место свойствам.
    Отредактировано 19.03.2016 19:46 xy012111 . Предыдущая версия .
    Re: Информация для разработчиков библиотеки
    От: IT Россия linq2db.com
    Дата: 20.03.16 16:17
    Оценка: +1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Если у вас нет лицензии на решарпер — используйте хотя бы бесплатные Resharper Command Line Tools.


    Кстати, через пару тройку месяцев всем активным участникам проекта можно будет запросить open source лицензию решарпера.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[6]: Информация для разработчиков библиотеки
    От: Sinix  
    Дата: 07.04.16 09:51
    Оценка: +1
    Здравствуйте, 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 поля правильная — см сюда.

    Ещё вопросы?
    Отредактировано 07.04.2016 12:46 Sinix . Предыдущая версия .
    Re[7]: Информация для разработчиков библиотеки
    От: xy012111  
    Дата: 07.04.16 10:21
    Оценка: :)
    Здравствуйте, AndrewVK, Вы писали:

    X>>Вообще, и статические поля совсем не нужны


    AVK>Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись.


    С чего вы взяли, что я выставлял её как истину в последней инстанции?

    Я лишь привёл пример точки зрения, которая делает различие между одним и другим. Вы же не категорически высказались против, не привели никакой причины, а лишь сказали, что не видите существенной разницы. Ну если вы не видите, то я показал, что видят, как минимум, другие. Чего тут не понятного? Дело хозхяйское, куда смотреть и смотреть ли вообще и что считать существенным.

    /* Вот NRE из CodeJam пользователь может огрести из ста тыщ пятиста мест, если для вас это не существенно, если такая забота об аргументах, по вашему мнению, должна делаться клиентом, ваше право ;о) Но и тут многие с вами не согласятся */

    Вот если не сочтёте за труд посмотреть на BCL, то сможете заметить, что мест, где наружу торчат экземплярные поля раз-два и обчёлся. Я вот даже и не припомню ни одного.

    Относительно статических полей немного другая картина: кой-где, даже много где, они торчат. Но или со времён ещё первого дотнета, когда ни о каких гайдлайнах не слышали и, быть может, вовсе не задумывались о каком-то дизайне, или по другим причинам. Скорее всего, просто из-за невозможноси проинициализировать свойство при объявлении. Разносить инициализацию и объявление, при необходимости объявлять, к примеру, десятки DependencyProperty и ключей к ним действительно проблема.

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

    Я для себя это объясняю просто — поле это нечто "физическое", "способ реализации" который не здорово выставлять наружу. А вот свойство — это некий контракт. Извне, пользователям типа, не важен способ реализации, необходим только контракт. Так и не нужно им пихать поле когда достаточно дать свойство.
    Re[9]: Информация для разработчиков библиотеки
    От: xy012111  
    Дата: 07.04.16 13:05
    Оценка: :)
    Здравствуйте, 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.Default Field и Comparer&lt;T&gt;.Default Property. Почему в старой ламповой версии так, а в более современной сяк?
    Re[10]: Информация для разработчиков библиотеки
    От: Sinix  
    Дата: 07.04.16 14:18
    Оценка: +1
    Здравствуйте, xy012111, Вы писали:


    X>Если нужна пища для размышления, сравните Comparer.Default Field и Comparer&lt;T&gt;.Default Property. Почему в старой ламповой версии так, а в более современной сяк?


    Вам поспорить, или разобраться?
    Если второе, то лучший способ — сравнить самому код Comparer(of T) и Comparer.


    Если не очевидно,
      2all: сорри за спойлер
    Создание Comparer<T> включает в себя эмит кода для генерик-класса и должно выполняться лениво, не блокируя другие потоки.

    В случае с полем инициализация выполнялась бы при первом обращении к самому типу (точнее, не позже чем, там beforefieldinit емнип) и завешивала бы все потоки, пытающиеся обратиться к этому типу, включая наследников Comparer<T>.


    Если вам интересно — вы во-первых спрашивайте вопросы нормально, не изображая владельца тайного знания, а во-вторых — в профильном разделе. Всегда вэлкам
    Re[12]: Информация для разработчиков библиотеки
    От: Sinix  
    Дата: 07.04.16 15:22
    Оценка: +1
    Здравствуйте, xy012111, Вы писали:

    X>Ну наконец-то! Теперь представьте ситуёвину: у вас торчит наружу открытое статическое поле, а в новой версии библиотеки вы вдруг понимаете, что сделав ленивое вычисление значения, присваевоемого этому полю, вы можете что-то улучшить в возвращаемом значении.



    Просто прочтите наконец 5.5 Field design, главка на страницу. Там даже пример, что такое "predefined object instance" есть. И сразу ниже этого абзаца — рекомендация на случай, если значение будет меняться.
    А то ваши возражения пока выглядят вот так вот: матчасть не читал, но мнение имею.

    Без обид



    X>А вот обратного примера, когда потребовалась бы замена свойства на поле я не знаю.

    Огосспидя, вы когда начинаете спорить — забрало не опускайте

    Ответы вам пишут не для переспорить, а подкинуть информацию для размышлений. Сценарии, когда свойство не заменит поле, я приводил выше.
    Re: CodeJam Roadmap
    От: xy012111  
    Дата: 16.03.16 23:10
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    Тут же лучше обсуждать, правильно?

    Компилироваться шестым шарпом будет?

    AVK>Расширения для строки


    Пригодятся ли такие же инфиксные расширения для Array? Все статические методы этого класса, где первым параметром Array или T[]?

    AVK>Расширения для коллекций

    AVK> * AsArray, AsList, AsHashSet

    AsReadOnlyCollection, AsReadOnlyList (по аналогии с Enumerable::AsEnumerable)?

    AVK>Расширения для словарей

    AVK> * GetValueOrDefault

    Для какого типа это будет расширением? Если сделать для IDictionary<,> то не будет работать для IReadOnlyDictionary<,> (и vice versa); если сделать для обоих, то компилятор откажется компилировать вызов у Dictionary<,>

    AVK>Прочее


    Memoize я так понял не нужен?
    Re[2]: CodeJam Roadmap
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.03.16 23:26
    Оценка:
    Здравствуйте, 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>>
    AVK Blog
    Re[3]: CodeJam Roadmap
    От: xy012111  
    Дата: 16.03.16 23:45
    Оценка:
    Здравствуйте, 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<>
    Re: CodeJam Roadmap
    От: Lexey Россия  
    Дата: 17.03.16 18:50
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    Я там пул-реквест завел с изменениями (косметика + фикс обработки ситуации, когда после "равных" чисел нужно продолжать сранение строк) к NaturalStringComparer и 3-мя вопросами в TODO по нему и методу Args(string format....).
    Посмотри, pls.
    "Будь достоин победы" (c) 8th Wizard's rule.
    Re[2]: CodeJam Roadmap
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.03.16 19:38
    Оценка:
    Здравствуйте, 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>>
    AVK Blog
    Re: CodeJam - библиотека универсальных полезняшек для .NET
    От: α Российская Империя  
    Дата: 17.03.16 19:41
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    apache commons (java) вдохновляться планируете?
    Re[2]: CodeJam - библиотека универсальных полезняшек для .NET
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.03.16 19:57
    Оценка:
    Здравствуйте, ?, Вы писали:

    ?>apache commons (java) вдохновляться планируете?

    Если там есть чем — почему бы нет. Полезное и подходящее по теме спортировать недолго.
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
    AVK Blog
    Re[2]: CodeJam - библиотека универсальных полезняшек для .NET
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.03.16 23:19
    Оценка:
    Здравствуйте, 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>>
    AVK Blog
    Re: CodeJam - библиотека универсальных полезняшек для .NET
    От: Jack128  
    Дата: 18.03.16 07:02
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    А куда замечания/вопросы по либе писать?

    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.

    2)
    В чем смысл этого?? https://github.com/rsdn/CodeJam/blob/778d3cde52d8648279a521f5e675ac5d78d358b9/Main/src/Collections/CollectionExtensions.cs (AsArray/AsList...)
    Может имелось в виду что нить типа такого AsArray<T>(this IEnumerable<T> source) => (source as T[]) ?? source.ToArray() ? тогда было бы полезнее иметь AsReadOnlyList
    Отредактировано 18.03.2016 7:04 Jack128 . Предыдущая версия . Еще …
    Отредактировано 18.03.2016 7:04 Jack128 . Предыдущая версия .
    Re[2]: CodeJam - библиотека универсальных полезняшек для .NET
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.03.16 07:43
    Оценка:
    Здравствуйте, Jack128, Вы писали:

    J>Почему Concat ?? ИМХО логичнее было бы Append.


    Потому что Enumerable.Concat уже есть.

    J>2)

    J>В чем смысл этого?? https://github.com/rsdn/CodeJam/blob/778d3cde52d8648279a521f5e675ac5d78d358b9/Main/src/Collections/CollectionExtensions.cs (AsArray/AsList...)

    Это лучше к rameel — Re[2]: Проект утилитной библиотечки
    Автор: rameel
    Дата: 16.03.16


    J>Может имелось в виду что нить типа такого AsArray<T>(this IEnumerable<T> source) => (source as T[]) ?? source.ToArray() ?


    Вряд ли. Enumerable.AsEnumerable видел в Fx? Знаешь зачем он нужен?
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
    AVK Blog
    Re[3]: CodeJam - библиотека универсальных полезняшек для .NET
    От: Jack128  
    Дата: 18.03.16 08:16
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Здравствуйте, Jack128, Вы писали:


    J>>Почему Concat ?? ИМХО логичнее было бы Append.


    AVK>Потому что Enumerable.Concat уже есть.


    Эт я понимаю, но вот честно, если б меня спросили:
    "есть метод, который добавляем элемент в начало последовательности, он называется Prepend. Как называется метод который добавляет элемент в конец последовательности?"
    я б вряд ли сказал Concat.

    J>>2)

    J>>В чем смысл этого?? https://github.com/rsdn/CodeJam/blob/778d3cde52d8648279a521f5e675ac5d78d358b9/Main/src/Collections/CollectionExtensions.cs (AsArray/AsList...)

    AVK>Это лучше к rameel — Re[2]: Проект утилитной библиотечки
    Автор: rameel
    Дата: 16.03.16


    Ну так четко же написано:
    >> Разный набор методов типа 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
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.03.16 08:20
    Оценка:
    Здравствуйте, 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>>
    AVK Blog
    Re[3]: CodeJam Roadmap
    От: rameel https://github.com/rsdn/CodeJam
    Дата: 18.03.16 12:42
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Насчет названия для формата — тут ХЗ. В моей либе оно FormatStr называется. Args это IT использует, соотв. оно и в linq2db присуствует. Просто Format, к сожалению, назвать нельзя. Если брать текущую терминологию шарпа, то тогда следует обозвать Interpolate по аналогии со string interpolation.


    Видел еще вариант FormatWith
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
    Re[2]: CodeJam - библиотека универсальных полезняшек для .NET
    От: rameel https://github.com/rsdn/CodeJam
    Дата: 18.03.16 12:42
    Оценка:
    Здравствуйте, Jack128, Вы писали:

    J>2)

    J>В чем смысл этого?? https://github.com/rsdn/CodeJam/blob/778d3cde52d8648279a521f5e675ac5d78d358b9/Main/src/Collections/CollectionExtensions.cs (AsArray/AsList...)

    J>Может имелось в виду что нить типа такого AsArray<T>(this IEnumerable<T> source) => (source as T[]) ?? source.ToArray() ?


    Да, так и планировалось, был занят. Сейчас как раз пишу, скоро закоммичу
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
    Re: CodeJam - библиотека универсальных полезняшек для .NET
    От: rameel https://github.com/rsdn/CodeJam
    Дата: 18.03.16 12:44
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    Кстати, как заставить решарпер применять локальные настройки проекта? Раньше проблем не замечал, а сейчас что ни делаю, все равно пробелы вместо табов вставляет
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
    Re[3]: CodeJam - библиотека универсальных полезняшек для .NET
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.03.16 12:52
    Оценка:
    Здравствуйте, rameel, Вы писали:

    R>Да, так и планировалось, был занят. Сейчас как раз пишу, скоро закоммичу


    Тогда имя надо другое. As вводит в заблуждение.
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
    AVK Blog
    Re[2]: CodeJam - библиотека универсальных полезняшек для .NET
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.03.16 12:53
    Оценка:
    Здравствуйте, rameel, Вы писали:

    R>Кстати, как заставить решарпер применять локальные настройки проекта? Раньше проблем не замечал, а сейчас что ни делаю, все равно пробелы вместо табов вставляет


    Пробелы — никак, решарпер ими не управляет, это студийная неотключаемая настройка. Возможно упомянутый тут editconfig спасет.
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
    AVK Blog
    Re[4]: CodeJam - библиотека универсальных полезняшек для .NET
    От: rameel https://github.com/rsdn/CodeJam
    Дата: 18.03.16 12:57
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Тогда имя надо другое. As вводит в заблуждение.


    Можно, а какое?
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
    Re[5]: CodeJam - библиотека универсальных полезняшек для .NET
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.03.16 13:05
    Оценка:
    Здравствуйте, rameel, Вы писали:

    AVK>>Тогда имя надо другое. As вводит в заблуждение.

    R>Можно, а какое?

    ХЗ. ToArray занято. MakeArray, CastToArray?
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
    AVK Blog
    Re[2]: Информация для разработчиков библиотеки
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 19.03.16 21:53
    Оценка:
    Здравствуйте, xy012111, Вы писали:

    X>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства?

    X>Поля это всё ж некоторые инструменты (детали) реализации, а в интерфейсе самое место свойствам.

    Честно говоря не вижу никакой существенной разницы между readonly полем и свойством.
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
    AVK Blog
    Re[6]: CodeJam - библиотека универсальных полезняшек для .NET
    От: IT Россия linq2db.com
    Дата: 20.03.16 16:15
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>>>Тогда имя надо другое. As вводит в заблуждение.

    R>>Можно, а какое?
    AVK>ХЗ. ToArray занято. MakeArray, CastToArray?

    Чего вы мучаетесь? AsArray, AsList используется уже в куче проектов, которые я видел. Никаких проблем. Вообще.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re: CodeJam - библиотека универсальных полезняшек для .NET
    От: Evgeny.Panasyuk Россия  
    Дата: 21.03.16 00:45
    Оценка:
    Тему бы закрепить.
    Re[3]: Информация для разработчиков библиотеки
    От: xy012111  
    Дата: 07.04.16 07:07
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    X>>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства?

    X>>Поля это всё ж некоторые инструменты (детали) реализации, а в интерфейсе самое место свойствам.

    AVK>Честно говоря не вижу никакой существенной разницы между readonly полем и свойством.


    Как минимум тут, Field Design, первый же пункт:

    X DO NOT provide instance fields that are public or protected.

    You should provide properties for accessing fields instead of making them public or protected.

    Re[5]: Информация для разработчиков библиотеки
    От: xy012111  
    Дата: 07.04.16 09:10
    Оценка:
    Здравствуйте, Sinix, Вы писали:

    X>>>>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства?

    X>>Как минимум тут, Field Design, первый же пункт:

    S>FDG надо читать, а не просто цитировать.


    Избавьте. Не читать нужно, а понимать. И не только смысл, но и причины.

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

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

    Требование же о неизменячемости типа readonly полей совершенно бредово: его выполнение приводит к запрету
    private readonly List<int> values…
    private readonly ObjectPool<чего-то там> pool…

    например и тому подобному. Надеюсь, причины появления этой ереси в гайдлайнах вам известны? Они более чем "для дураков".

    S>Разобрались?


    Большущее спасибо, без вас бы никак.
    Re[11]: Информация для разработчиков библиотеки
    От: xy012111  
    Дата: 07.04.16 15:06
    Оценка:
    Здравствуйте, Sinix, Вы писали:

    X>>Если нужна пища для размышления, сравните Comparer.Default Field и Comparer&lt;T&gt;.Default Property. Почему в старой ламповой версии так, а в более современной сяк?


    S>Вам поспорить, или разобраться?


    Спилите мушку.

    S>Если второе, то лучший способ — сравнить самому код Comparer(of T) и Comparer.


    Ну наконец-то! Теперь представьте ситуёвину: у вас торчит наружу открытое статическое поле, а в новой версии библиотеки вы вдруг понимаете, что сделав ленивое вычисление значения, присваевоемого этому полю, вы можете что-то улучшить в возвращаемом значении. И приходится либо терять совместимость либо пристраивать костыли. А свойство рррраз! И всё. В любой момент внутренности можно как угодно допилить.

    А вот обратного примера, когда потребовалась бы замена свойства на поле я не знаю. Поэтому наружу только свойства. Это проще запоминать, всегда можно до-пере-пилить. Ни одного преимущества у полей нет. У свойств они, пускай, не очевидны и не всегда нужны, но всё же есть.

    S>Если вам интересно — вы во-первых спрашивайте вопросы нормально, не изображая владельца тайного знания, а во-вторых — в профильном разделе. Всегда вэлкам


    Большое спасибо!
    Re[10]: Информация для разработчиков библиотеки
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 07.04.16 19:21
    Оценка:
    Здравствуйте, 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>Мне, когда смотрел код, достаочно было увидеть в одном месте, что бы озадачиться. Надо было всё перечитать прежде чем написать?

    Надо было спросить.

    X> Comparer.Default Field и Comparer&lt;T&gt;.Default Property. Почему в старой ламповой версии так, а в более современной сяк?


    Дело не в современности, дело в ленивой инициализации.
    ... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
    AVK Blog
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.