Да, прекрасно знаю об этом, однако прикрепил в конец статьи proposals, которые некоторые рассматривали как альтернативу для решения задачи обобщения алгоритмов, в том числе в обсуждении Generic Math в GitHub.
К сожалению, при ФП подходе придётся крафтить что-то вроде Scala implicits, а этого никто в здравом уме конечно делать не будет. Поэтому, для C# был избран другой путь, как мне кажется более подходящий.
Согласен, есть такое! Однако, для тех кому не хватило оставил источники в конце и основной посыл статьи достаточно простой.
Когда используете какой-то инструмент, всегда держите в голове идею и point его создателя, чтобы не противоречить базовым design principles. Потому что, если выходит так, что не получается использовать инструмент по назначению, проще не тратить силы на попытки его встроить, а сменить или отказаться
Не хватило ещё SearchValues в статье
Да, прекрасно знаю об этом, однако прикрепил в конец статьи proposals, которые некоторые рассматривали как альтернативу для решения задачи обобщения алгоритмов, в том числе в обсуждении Generic Math в GitHub.
К сожалению, при ФП подходе придётся крафтить что-то вроде Scala implicits, а этого никто в здравом уме конечно делать не будет.
Поэтому, для C# был избран другой путь, как мне кажется более подходящий.
Да, уже говорили об этом в комментариях к предыдущим статьям по теме
Спасибо, опечатался с Y компонентой
Недокрутили мысль, к сожалению( Изобрели велосипед и рассказали о каком-то рафинированном CQRS
https://twitter.github.io/algebird/datatypes/approx/hyperloglog.html
Интересный пример! Кстати про первый снимает статья даже была, Fluent Generics называлась. Не думал, что встречу ещё где-то этот подход
https://habr.com/ru/post/666244/
На дворе был 2022 год...
по 3 пункту гляньте Refit https://github.com/reactiveui/refit
Спасибо! О расширениях было написано в статье
Собственно, данный вариант описан в статье
Эта история уже из немного другой оперы
Спасибо за конструктивный комментарий!
Да, компилятор конечно не заставишь ругаться, но можно использовать xmldoc тег
<exception>https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/xmldoc/recommended-tags#exception
Про делегаты написал ещё в статье, что их существование аннулирует необходимость функциональных интерфейсов:
Хотел так написать в интро к посту кстати) так и думал, что будет такой комментарий) скоро как раз про это выпущу статью
Лучшим способом реализовать Union Type было бы сделать монаду Either, а не встраивать это через ООП
Рекомендую ознакомиться с этой статьей, где описано, как устроена алгебра типов
https://bartoszmilewski.com/2015/01/13/simple-algebraic-data-types/
Согласен, есть такое! Однако, для тех кому не хватило оставил источники в конце и основной посыл статьи достаточно простой.
Когда используете какой-то инструмент, всегда держите в голове идею и point его создателя, чтобы не противоречить базовым design principles. Потому что, если выходит так, что не получается использовать инструмент по назначению, проще не тратить силы на попытки его встроить, а сменить или отказаться
А где информация по поводу того, что в .net 7 уже будут стабильными?
Да, вы правы, отметил это в статье. Однако, проблема всё же возникнет при использовании
Result<T, T>. В этом основной поинт)