Re: TODOs - Библиотека CodeJam

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

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

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

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

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

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

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

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

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

* 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();

Отредактировано 16.12.2016 8:53 Sinix . Предыдущая версия .

Отредактировано 16.12.2016 5:55 Sinix . Предыдущая версия .

Отредактировано 23.09.2016 12:24 Sinix . Предыдущая версия .

Отредактировано 22.09.2016 13:16 Sinix . Предыдущая версия .

Отредактировано 22.09.2016 12:17 Sinix . Предыдущая версия .

Отредактировано 22.09.2016 10:46 Sinix . Предыдущая версия .

Отредактировано 11.08.2016 17:38 Sinix . Предыдущая версия .

Отредактировано 11.08.2016 17:36 Sinix . Предыдущая версия .

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

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

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

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

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

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

Здравствуйте, 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.

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

Здравствуйте, 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.
Ага, в планах было, но только завтра смогу.

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

S>Ага, давай

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

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

Здравствуйте, 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 подхватились.

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

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

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

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

Пусть AndrewVK ещё глянет, может какие замечания будут.

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

	От:	Sinix
	Дата:	17.07.16 09:26
	Оценка:

	От:	Jack128
	Дата:	17.07.16 10:20
	Оценка:	+1

	От:	Sinix
	Дата:	17.07.16 10:24
	Оценка:

	От:	Lexey
	Дата:	18.07.16 14:25
	Оценка:	44 (1)

	От:	Sinix
	Дата:	18.07.16 14:54
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	20.08.16 20:10
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	20.08.16 23:35
	Оценка:

От:	_NN_	www.nemerleweb.com
Дата:	16.12.16 08:45
Оценка:	153 (3)

От:	rameel	https://github.com/rsdn/CodeJam
Дата:	22.12.16 12:20
Оценка: