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

Пока в awesome .net не добавили.
Но добавили в https://github.com/Microsoft/dotnet

https://github.com/Microsoft/dotnet/blob/master/dotnet-developer-projects.md

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

Добавил ещё и в https://github.com/tallesl/net-libraries-that-make-your-life-easier

Вроде ещё проектов в github со списками нет.

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

S>* Прописаться в awesome dotnet list. Чтоббыло.
Запросил изменение, будем ждать.

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

R>Частично есть еще InterlockedOperations: InterlockedOperations.cs

R>Хотя... кода там одна строчка, и который сам собой напрашивается
Ну да. Там отсылка не к конкретной реализации, а к алгоритму. Как пруф, что должно работать.

То же самое можно из исходников фреймворка или из сгенеренного кода для событий вытащить.
В общем, если нам нужно принципиально отвязаться от кода под апач-лицензией, код можем из другого источника взять. Ну, или переписать (хотя там и переписывать-то нечего).

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

S>Ага, давай

Вот, сделал:
https://github.com/rsdn/CodeJam/pull/24

Заодно подправил там слегка CreateTempFile и CreateTempDirectory, чтобы файл/директория удалялись финализатором, если что-то пойдет не так в процессе выполнения самого метода.

Поправил замечания и BugIf приделал.

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

S>1. Методы Code.BugIf() / DebugCode.BugIf(). Смысл такой: регулярно в процессе разработки закладываешься на какой-то факт, если надежды обломались — всё, приплыли.

Тогда лучше Code.BugIfNot, чтобы поведение было аналогично AssertState.

S>В общем, тот же Code.AssertState, но вина не пользователя API, а самого разработчика. Почему не использовать сам AssertState? Чтоб проще было отличать.

Удивил. Я срабатывание AssertState как раз рассматриваю как вину разработчика, ибо Assert в других языках используется именно для диагностики внутренних ошибок логики, а не неверного использования API.

У меня тоже пара хотелок образовалась:
1) Code.ValidCount — по сути тоже самое, что ValidIndex, но явно видно, что проверяется длина.
2) Возможность в лоб создать TempFile без создания самого файла. Сейчас мне для этого приходится самому реимплементить функцию создания пути временного файла, чтобы скормить путь в констуктор TempFile.

Могу сам добавить, если не будет возражений.

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

AVK>Ну тогда просто выкинуть и все. Тем более что там и с доккоментами все довольно печально.

Выкинул, в README добавил notices по остальным заимствованиям.

Да, CodeJam.Main.FW35.csproj вообще актуален? Там часть путей (как минимум к Algorithms.EqualRange.Comparer.cs и тыды) старая.

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

AVK>>Ну тогда просто выкинуть и все. Тем более что там и с доккоментами все довольно печально.
S>Ок, если rameel не против.

Я не против

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

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

_NN>Похоже нужно добавить голосов в комментарий andrewvk, чтобы наконец приняли.
_NN>https://github.com/quozd/awesome-dotnet/pull/451#issuecomment-267849370

Гхмм... какой-то неправильный awesome-dotnet. Не, часть претензий вполне законна, про документацию нам писали все. А вот агитация за копипасту с SO выглядит забавно Да, а товарищ вообще автор репо, или на огонёк зашёл?


Второе возражение, про слишком много всего — частично тож справедливо.
Я бы разнёс чисто bcl-штуки (enumerable extensions, ассерты, operators и тыды) и бизнес-вещи типа маппинга, csv, service provider по разным пакетам.
Это в порядке предложения, воевать за него я не готов

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

S>3. Что-то типа
S>

S>var baseTypesAndSelf = Algorithms.WhileNotNull(type, t => t.BaseType).ToArray();
S>

Сильно похоже на Seq.Unfold

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

R>Частично есть еще InterlockedOperations: InterlockedOperations.cs

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

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

S>>Сейчас CodeJam — всё и обо всём,
AVK>Он таким и задумывался.
Ну это не совсем ок, потому что у нас с позиционированием проблемы.
Библиотека для "хелперы к фреймворку" — одно, библиотека для "сделай свой фреймворк" — другое, надо бы разнести.

AVK>Как то слишком нечетко и искусственно, имхо.
Ну да, это общий критерий, который позволяет быстро ответить на вопрос "что выбрать?". По факту точно надо вынести папки Services, Mapping, Metadata, TableData.


S>>А, да, насчёт стандартов, можно всё-таки const (и поля, и переменные) с заглавной сделать?
AVK>Приватные?
Ага.

S>> Пожалуй единственный пункт, который резко отличается от всех остальных проектов. Раздражает
AVK>Это где приватные поля с заглавной буквы?
Как пример: corefx, поискать "private const" в кавычках. Ссылка:

https://github.com/dotnet/corefx/search?utf8=✓&q="private+const"

Ну и не поля, а константы. То, что константа как поле хранится — это чисто деталь реализации. Приватные Enum-ы ж с заглавной — норм.


P.S. Да, в
\Main\src\Structures\OneOf\IOneOf.tt
мелкий косяк: include file="OneOfCommon.ttinclude" — нет такого.

Проверить можно через build — transform all templates

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

S>>Библиотека для "хелперы к фреймворку" — одно, библиотека для "сделай свой фреймворк" — другое, надо бы разнести.
AVK>Так а какой бенефит в итоге получится от этого? Вот геморой от двух разных сборок и двух разных пакетов очевиден.
С моей точки зрения —
1. Явное разделение зависимостей на слои. Если хелперы начинают тянуть за собой код из, скажем, маппинга, то что-то явно пошло не так
2. Никаких вопросов на тему "ок, мы берём хелперы, но нам не нужна работа с csv, потому что у нас есть своя единственно верная реализация". Таки реальный отзыв. Обоснование было примерно такое: ну вот берёшь ты библиотеку-провайдер для СУБД, а с ней в нагрузку — свой ORM. Впечатление, как будто защитник от mail.ru впаривают Конец цитаты.
3. Меньше борьбы за "весь код должен быть отличным". Ну есть косяки в дизайне отдельных вещей — пусть себе лежат в библиотечке для авторов фреймворков и конечным пользователям не мешают.

Про версии — нет никакого геммороя, главное чтоб релизы обоих сборок выпускались одновременно. Я ж 4 сборки для перфтестов как-то обновляю и ок.


AVK>Кто в лес, кто по дрова.
Ага, есть такое дело. Но с заглавной гораздо чаще встречается. Проверил в репо рослина — тож самое. Во всех проектах, где работал, в другом кейсе писал в основном народ, пересевший с других языков. Выборка не факт что репрезентативная, поэтому за аргумент не катит

S>>Ну и не поля, а константы. То, что константа как поле хранится — это чисто деталь реализации.
AVK>https://github.com/dotnet/corefx/search?utf8=%E2%9C%93&q=%22private+static+readonly%22
AVK>Семантически очень близкие сущности выглядят совершенно по разному. Нафига нам этот геморой?
Ухтыж, забавно. В смысле, с моей точки зрения константы гораздо ближе к enum members чем к полям. Если рассматривать константы как поля — то да, твой вариант логичнее. Если остальных устраивает — ок.


S>> Приватные Enum-ы ж с заглавной — норм.
AVK>Енум это тип, а не поле.
Я про enum members. Не, понятно, что под капотом у enum member — public const field, но это чисто деталь реализации.


AVK>Какие то хвосты остались. Поправил
Ок, спасиб!

Краткий список штук, которые неплохо бы добавить в CodeJam. У самого руки не доходят, перфтесты допиливаю

Автор: Sinix
Дата: 08.12.16

(и там таки тоже нужна помощь, если кто хочет поучаствовать).

TODO:
* Хелперы для ФС: Перебор файлов с учётом ACL

Автор: DreamMaker
Дата: 22.09.16

* Мелкий баг в MinBy (в похожих методах тоже может быть, не проверял). Для значений с null-ключом побеждает последний элемент, для всех остальных значений — первый.

* Прописаться в awesome dotnet list. Чтоббыло.

* Проверить наличие тестов ч/з code coverage. Как минимум для string extensions их не хватает

Автор: Vasiliy2
Дата: 22.09.16

.

UPD:
* Только сейчас заметил. У нас есть копии типов из фреймворка для совместимости с .net 4.0 и младше. В сборках под старшие версии для них надо type forwarding указать. Надо будет поправить.

DONE:
* Методы Code.BugIf() / DebugCode.BugIf(). Смысл такой: регулярно в процессе разработки закладываешься на какой-то факт, если надежды обломались — всё, приплыли.
В общем, тот же Code.AssertState, но вина не пользователя API, а самого разработчика. Почему не использовать сам AssertState? Чтоб проще было отличать.

* EnumCode.Xxx() — ассерты для энумов. Полный аналог Code, содержит методы-ассерты для всех методов из EnumHelper, исключения в классе EnumCodeExceptions. Нудятина страшная, наверно сам сделаю.

* Поправить ConcurrentLazyDictionary. Подробнее — см реквест

Автор: LWhisper
Дата: 11.08.16

. Пример реализации — тынц.

* GroupWhile. Тот же GroupBy, но с учётом порядка значений, как минимум две перегрузки — по предикату и по ключу группировки. Примеры сценариев:
http://stackoverflow.com/a/22415704/318263
http://stackoverflow.com/a/11311070/318263
https://msdn.microsoft.com/en-us/library/cc138361.aspx

* (Done as Sequence)Что-то типа

var baseTypesAndSelf = Algorithms.WhileNotNull(type, t => t.BaseType).ToArray();

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

J>Сильно похоже на Seq.Unfold
Ага, оно. Только название надо подобрать так, чтобы оно у большинства разработчиков под шарп вопросов не вызывало.

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

S>>1. Методы Code.BugIf() / DebugCode.BugIf(). Смысл такой: регулярно в процессе разработки закладываешься на какой-то факт, если надежды обломались —
L>Тогда лучше Code.BugIfNot, чтобы поведение было аналогично AssertState.
Не, там двойное отрицание тогда получится в 99% случаев. Сам попробуй вспомнить типовые примеры, у меня оно выглядит обычно как-то так:

BugIf(count > 10e6, "???");
...
BugIf(cachedInstance == null, "o_O?");
...
BugIf(newValue == oldOne, "...");

Если у тебя наоборот — накидывай свои примеры, может, оба варианта сделаем


L>Удивил. Я срабатывание AssertState как раз рассматриваю как вину разработчика, ибо Assert в других языках используется именно для диагностики внутренних ошибок логики, а не неверного использования API.
Ну вот у меня AssertState, насколько помню, везде используется для сообщения о том, что объект используется извращённым способом. Ну, например, попытка закоммитить откаченнную транзакцию или получить результат ещё не запущенного теста. А BugIf, наоборот, для ситуаций, которые в теории возникнуть не могут вообще, а на практике лучше сразу упасть, чем продолжать работу. Т,е. для стопроцентных багов.



L>У меня тоже пара хотелок образовалась:
L>1) Code.ValidCount — по сути тоже самое, что ValidIndex, но явно видно, что проверяется длина.
Принято вместе с названием

L>2) Возможность в лоб создать TempFile без создания самого файла. Сейчас мне для этого приходится самому реимплементить функцию создания пути временного файла, чтобы скормить путь в констуктор TempFile.
А оно было вроде. Или это для Dictionary такое делалось. Не вспомню. В общем — да, конечно.

L>Могу сам добавить, если не будет возражений.
Ага, давай

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

S>>>1. Методы Code.BugIf() / DebugCode.BugIf(). Смысл такой: регулярно в процессе разработки закладываешься на какой-то факт, если надежды обломались —
L>>Тогда лучше Code.BugIfNot, чтобы поведение было аналогично AssertState.
S>Если у тебя наоборот — накидывай свои примеры, может, оба варианта сделаем

ОК, убедил. Моя идея была только в том, чтобы можно было спокойно заменить AssertState на BugIf, не переворачивая условия. Но, это не принципиально.

L>>Могу сам добавить, если не будет возражений.
S>Ага, давай

ОК.

P.S. Посмотри, кстати, методы, которые я там для SuffixTree добавил, pls.

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


L>P.S. Посмотри, кстати, методы, которые я там для SuffixTree добавил, pls.
Ага, в планах было, но только завтра смогу.

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

L>Заодно подправил там слегка CreateTempFile и CreateTempDirectory, чтобы файл/директория удалялись финализатором, если что-то пойдет не так в процессе выполнения самого метода.
Ага, отписался там уже. Всё по мелочи, если самому лень / неудобно — не вопрос, поправлю после мержа.

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

L>>Заодно подправил там слегка CreateTempFile и CreateTempDirectory, чтобы файл/директория удалялись финализатором, если что-то пойдет не так в процессе выполнения самого метода.
S>Ага, отписался там уже. Всё по мелочи, если самому лень / неудобно — не вопрос, поправлю после мержа.

Thnx. Сегодня вечером постараюсь поправить.
BugIf кто будет писать?

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

L>Thnx. Сегодня вечером постараюсь поправить.
L>BugIf кто будет писать?
Если возьмёшься — будет классно

Да, ещё надо будет шаблон T4 для DebugCode перезапустить, чтоб правки в Code подхватились.

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

L>>BugIf кто будет писать?
S>Если возьмёшься — будет классно

Сделаю.

S>Да, ещё надо будет шаблон T4 для DebugCode перезапустить, чтоб правки в Code подхватились.

Да, забыл про это.

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

L>Поправил замечания и BugIf приделал.
Ага, увидел, всё ок Пусть AndrewVK ещё глянет, может какие замечания будут.

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

S>UPD. 6. Поправить ConcurrentLazyDictionary. Подробнее — см реквест

Автор: LWhisper
Дата: 11.08.16

. Пример реализации — тынц.

Поправил — добавил в фабрику перегрузку с LazyThreadSafetyMode вместо булевого флажка.
Важно: поведение старого метода со значением флажка true изменилось — теперь возвращается реализация, в которой создание значения синхронизировано, т.е. гарантирует строго один запуск, но ценой блокировок и возможного дедлока.
Мне это не очень нравится, так как вариант без блокировок в большинстве случаев, имхо, предпочтительнее. Но консистентность с конструкторами Lazy<T> все таки важнее.
Просьба поревьювить — из-за нехватки времени пришлось делать подход к снаряду несколько раз, мог что то упустить.

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

L>Удивил. Я срабатывание AssertState как раз рассматриваю как вину разработчика, ибо Assert в других языках используется именно для диагностики внутренних ошибок логики, а не неверного использования API.

В том числе и для неверного использования API. Например отладочные версии STL. Может конечно там не непосредственно assert, а что-нибудь другое — но суть та же, отключаемые проверки.

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

Похоже нужно добавить голосов в комментарий andrewvk, чтобы наконец приняли.
https://github.com/quozd/awesome-dotnet/pull/451#issuecomment-267849370

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

S>Второе возражение, про слишком много всего — частично тож справедливо.
S>Я бы разнёс чисто bcl-штуки (enumerable extensions, ассерты, operators и тыды) и бизнес-вещи типа маппинга, csv, service provider по разным пакетам.
S>Это в порядке предложения, воевать за него я не готов

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

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

R>Вот не далее как вчера пришла такая мысль. Так что я поддержу предложение
R>Ассерты годная вещь и вполне самостоятельная, так что его даже в отдельный пакет засунуть можно

Не знаю, меня идея кучи микропакетов не радует. Разве что сделать один кумулятивный.

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

R>Вот не далее как вчера пришла такая мысль. Так что я поддержу предложение
R>Ассерты годная вещь и вполне самостоятельная, так что его даже в отдельный пакет засунуть можно
Не, это уже перебор.
А вот разделить чисто базовые вещи, которые должны по уровню соответствовать BCL и остальные штуки, к которым требования не такие строгие было бы классно.


Кстати, польза от awesome list уже есть. Камрад zihotki не поленился написать про косяк с лицензиями.

Временную быструю заглушку я закинул, теперь надо определиться, что делать дальше. Я бы решил проблему кардинально и выкинул ObjectPool к чертям.
Вроде бы у нас больше нет кода под Apache.

Во-первых, в дотнете планируются куда более интересные Span<T>/Memory<T> + ArrayPool<T>.
Во-вторых, одно дело включать код для таргетинга под 4.0 и совсем другое — скидывать чужой код в свой namespace.

Идея насчёт ObjectPool вроде была моя, но я первый готов признать, что получился неудобняк

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

AVK>Не знаю, меня идея кучи микропакетов не радует. Разве что сделать один кумулятивный.

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

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

А выделить ассерты в отдельный пакет я думал потому как, что ни библиотека так свой велосипед с Guard, Ensure, Require. С отдельным пакетом для ассертов, будет шанс, что люди быстрее согласятся ее использовать, чем писать свой недовелосипед, и детских страхов не будет, что там ой как много всего, что я не хочу. Но это так мысли вслух

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

S>Идея насчёт ObjectPool вроде была моя, но я первый готов признать, что получился неудобняк

Частично есть еще InterlockedOperations: InterlockedOperations.cs

Хотя... кода там одна строчка, и который сам собой напрашивается

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

S>Временную быструю заглушку я закинул, теперь надо определиться, что делать дальше. Я бы решил проблему кардинально и выкинул ObjectPool к чертям.

А это разве не ты его предложил добавить? Лично мое имхо — штука очень специфичная.

S>Идея насчёт ObjectPool вроде была моя, но я первый готов признать, что получился неудобняк

Ну тогда просто выкинуть и все. Тем более что там и с доккоментами все довольно печально.

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

AVK>А это разве не ты его предложил добавить? Лично мое имхо — штука очень специфичная.
Предлагал вроде я, по логу — добавил rameel.

S>>Идея насчёт ObjectPool вроде была моя, но я первый готов признать, что получился неудобняк
AVK>Ну тогда просто выкинуть и все. Тем более что там и с доккоментами все довольно печально.
Ок, если rameel не против.

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

S>Да, CodeJam.Main.FW35.csproj вообще актуален? Там часть путей (как минимум к Algorithms.EqualRange.Comparer.cs и тыды) старая.

Это отладочный проект, если для таргетинга в 3.5 надо много править и нужна поддержка студии.

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

S>>Да, CodeJam.Main.FW35.csproj вообще актуален? Там часть путей (как минимум к Algorithms.EqualRange.Comparer.cs и тыды) старая.

AVK>Это отладочный проект, если для таргетинга в 3.5 надо много править и нужна поддержка студии.
А, ну тогда как будет время — сравни его диффом с основным проектом. Я не хочу туда лезть, т.к. не знаю, что в этом проекте нужно, что нет.

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

_NN>Но добавили в https://github.com/Microsoft/dotnet


Ну, если честно, я рад, что в awesome нас пока нет — офигенный стимул довести проект до ума.

Потому что замечания-то по делу. Документация ёк, примеры ёк, overbloated — во все поля, развитие... ну пока я один отдуваюсь. Как-то не совсем awesome.

Единственный странный аргумент — про "по отдельности всё это есть". Проблема в том, что каждый мелкий хелпер даёт кучу положительного эффекта и новые пишутся буквально не думая. Тот же свежедобавленный interval tree — все ошибки выловили ассерты, тесты по сути как интеграционные тесты сработали.

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

S>Потому что замечания-то по делу.

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

S> Документация ёк, примеры ёк

Это было понятно и без.

S>overbloated — во все поля,

Можно конкретнее?

S> развитие... ну пока я один отдуваюсь.

Я тебе уже говорил — для конкретно этого проекта это нормально, что нет огромного количества изменений.

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

AVK>Там, по сути, одно замечание — лучше копипастить, чем использовать готовый вылизанный код. Остальное родилось, имхо, исключительно чтобы поспорить.
Ну да, позиция у zihotki своеобразная, но это не значит, что косяков у нас нет

S>>overbloated — во все поля,
AVK>Можно конкретнее?

А вот тут вот

Автор: Sinix
Дата: 22.12.16

.

Сейчас CodeJam — всё и обо всём, если разбить (имена условные), получается
* CodeJam.Core — дополнения к фреймворку и таргетинг (отсутствующие типы для младших версий .net)
* CodeJam.Enterprise — все фишки, которые нафиг не нужны для единичной библиотеки, но нужны авторам приложений или своих фреймворков.

Куча проблем уходит. Начиная с моего ворчания по поводу качества кода — оно критично только для базовых вещей, дополняющих готовый код из фреймворка

S>> развитие... ну пока я один отдуваюсь.
AVK>Я тебе уже говорил — для конкретно этого проекта это нормально, что нет огромного количества изменений.
Это _не_ нормально. В здоровом проекте есть всегда свободные work items. Т.е. мелкие ошибки типа того, что в начале темы, чинятся сразу, а не как настроение будет.
Ну и нет деления в духе "я правлю только свой код". Нашёл место, которое не устраивает — поправь сразу или с обсуждением в issues.

А, да, насчёт стандартов, можно всё-таки const (и поля, и переменные) с заглавной сделать? Пожалуй единственный пункт, который резко отличается от всех остальных проектов. Раздражает

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

S>Сейчас CodeJam — всё и обо всём,

Он таким и задумывался.

S> если разбить (имена условные), получается
S>* CodeJam.Core — дополнения к фреймворку и таргетинг (отсутствующие типы для младших версий .net)
S>* CodeJam.Enterprise — все фишки, которые нафиг не нужны для единичной библиотеки, но нужны авторам приложений или своих фреймворков.

Как то слишком нечетко и искусственно, имхо.

S>А, да, насчёт стандартов, можно всё-таки const (и поля, и переменные) с заглавной сделать?

Приватные?

S> Пожалуй единственный пункт, который резко отличается от всех остальных проектов. Раздражает

Это где приватные поля с заглавной буквы?

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

S>Библиотека для "хелперы к фреймворку" — одно, библиотека для "сделай свой фреймворк" — другое, надо бы разнести.

Так а какой бенефит в итоге получится от этого? Вот геморой от двух разных сборок и двух разных пакетов очевиден.

S>>> Пожалуй единственный пункт, который резко отличается от всех остальных проектов. Раздражает
AVK>>Это где приватные поля с заглавной буквы?
S>Как пример: corefx, поискать "private const" в кавычках. Ссылка:
S>

S>https://github.com/dotnet/corefx/search?utf8=?&q="private+const"
S>

Кто в лес, кто по дрова.

S>Ну и не поля, а константы. То, что константа как поле хранится — это чисто деталь реализации.

https://github.com/dotnet/corefx/search?utf8=%E2%9C%93&amp;q=%22private+static+readonly%22
Семантически очень близкие сущности выглядят совершенно по разному. Нафига нам этот геморой?

S> Приватные Enum-ы ж с заглавной — норм.

Енум это тип, а не поле.

S>P.S. Да, в
S>\Main\src\Structures\OneOf\IOneOf.tt
S>мелкий косяк: include file="OneOfCommon.ttinclude" — нет такого.

Какие то хвосты остались. Поправил

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

S> 1. Явное разделение зависимостей на слои. Если хелперы начинают тянуть за собой код из, скажем, маппинга, то что-то явно пошло не так

У нас в качестве одного из основных design goals заявлена минимальная связность. Поэтому такое маловероятно, по крайней мере в текущем составе контрибьюторов.

S> 2. Никаких вопросов на тему "ок, мы берём хелперы, но нам не нужна работа с csv, потому что у нас есть своя единственно верная реализация".

Да нет, вопросы все равно будут — всего два пакета их не снимут. Чтобы их не было, нужно чуть ли не каждую фичу в отдельный микропакет пихать.

S> Таки реальный отзыв. Обоснование было примерно такое: ну вот берёшь ты библиотеку-провайдер для СУБД, а с ней в нагрузку — свой ORM.

Это — другое. Вероятность что понадобится драйвер и не понадобится ОРМ — очень высока. А вот в случае предложенного деления — я в подобном сильно не уверен.

S> 3. Меньше борьбы за "весь код должен быть отличным".

Это — плохо.

S>Про версии — нет никакого геммороя, главное чтоб релизы обоих сборок выпускались одновременно. Я ж 4 сборки для перфтестов как-то обновляю и ок.

Тебе деваться некуда из-за зависимостей.

S>Ухтыж, забавно. В смысле, с моей точки зрения константы гораздо ближе к enum members чем к полям.

enum members это тоже поля. И они таки пишутся точно так же, как и поля. Просто они приватными быть не могут.

S>>> Приватные Enum-ы ж с заглавной — норм.
AVK>>Енум это тип, а не поле.
S>Я про enum members.

Они не бывают приватными.

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


AVK>У нас в качестве одного из основных design goals заявлена минимальная связность. Поэтому такое маловероятно, по крайней мере в текущем составе контрибьюторов.
AVK>Да нет, вопросы все равно будут — всего два пакета их не снимут. Чтобы их не было, нужно чуть ли не каждую фичу в отдельный микропакет пихать.

Окей, тогда остановимся на том что есть. Саммари: я за разделение, знакомый народ говорит что мы переборщили с фичами, rameel в теме тож за разделение, ну, т.е. реальные запросы есть и я их донёс надеюсь


AVK>Это — другое. Вероятность что понадобится драйвер и не понадобится ОРМ — очень высока. А вот в случае предложенного деления — я в подобном сильно не уверен.
Ну вот я в жизни не представлю, чтоб типовой дотнет-библиотеке понадобилась запись в csv, mapping или что-то в таком духе. Это всё ответственность хоста, т.е. приложения (фреймворка).

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

К примеру, у нас serviceProvider.GetService<T>() может возвращать null.
В проектах, в которых за дизайн отвечать мне, метод в public API с таким поведением будет называться TryGetService<T>() и никак иначе. Мелочь, но когда такая мелочь систематически выстреливает NullRefException быстро понимаешь, что мелочи решают.

Т.е. нашу реализацию я если и буду использовать, то только спрятанной под капотом.

И что самое прикольное, что поправить тут ничего нельзя. Если мы поменяем поведение и serviceProvider.GetService<T>() будет бросать исключение, то тут же взбунтуется вторая половина пользователей, которым NullRefException не страшны (к примеру, весь код решарпером на null проверяется) и важнее совместимость с фреймворком.

Короче, такие холиварные вещи, для которых есть куча равноправных решений, лучше делать opt-in. Чтобы не следить за тем, что в проекте случайно заюзалась "неправильная" реализация.



S>> 3. Меньше борьбы за "весь код должен быть отличным".
AVK>Это — плохо.

Это хорошо. Потому что "энтерпрайзный" код у нас в основном весь уже написан в одно лицо и у каждого одноголица свои привычки и свои критерии отличного кода. К примеру код от ув. IT почти весь использует выравнивание пробелами.
Имеет смысл бороться за одинаковое форматирование? Для мелочей типа тех что я добавляю — безусловно да, т.к. там нет никакой особой магии и поправить или написать подобное может любой с полпинка.
Для того же маппинга мы не получим никакого эффекта, только минус — маппинг по-прежнему будет оставаться ответственностью IT, а вся помошь от нас сведётся к "мы тебе оформление поменяли"


S>>Про версии — нет никакого геммороя, главное чтоб релизы обоих сборок выпускались одновременно. Я ж 4 сборки для перфтестов как-то обновляю и ок.
AVK>Тебе деваться некуда из-за зависимостей.
Так и тут то же самое будет, не вижу смысла разносить версии обоих библиотек.


S>>Я про enum members.
AVK>Они не бывают приватными.
Ну ок, точку зрения я донёс, дальше спорить не буду.

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

S>Окей, тогда остановимся на том что есть. Саммари: я за разделение, знакомый народ говорит что мы переборщили с фичами, rameel в теме тож за разделение, ну, т.е. реальные запросы есть и я их донёс надеюсь


Может опросом решить ?

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

S>>т.е. реальные запросы есть и я их донёс надеюсь

_NN>Может опросом решить ?
Неа. Опрос хорош как сбор реквестов от пользователей, но не как способ принятия решений в команде. Я терпеть не могу демократию внутри проекта — она в итоге ни к чему хорошему не приводит. Всегда должен быть лид, который и принимает конечное решение.

У нас это AndrewVK как автор проекта и человек, добровольно взваливший на себя всю организационную тягомотину

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

S>Неа. Опрос хорош как сбор реквестов от пользователей, но не как способ принятия решений в команде. Я терпеть не могу демократию внутри проекта — она в итоге ни к чему хорошему не приводит. Всегда должен быть лид, который и принимает конечное решение.

У меня пока определенного мнения нет, так что опрос не помешает.

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

AVK>У меня пока определенного мнения нет, так что опрос не помешает.
Ок. Заведёшь сам? Если нет — подскажи, как вставить голосование в пост?

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

AVK>>У меня пока определенного мнения нет, так что опрос не помешает.
S>Ок. Заведёшь сам? Если нет — подскажи, как вставить голосование в пост?

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