Comments 13
Я в Скале не очень понимаю, к сожалению, но, надеюсь, что понимаю в функциональном программировании. Я правильно понимаю, что для того, чтобы убедиться, что логирование не срезано как сайд-эффект, предлагается из функции возвращать что-то, что возвращает функция логирования? То есть возвращать такой результат, который вызывающему коду совсем не нужен, но он по сигнатуре будет понимать, что без логирования тут не обошлось...
Примерно так. Мы хотим на верхнем уровне программы иметь гарантию, что какие-то эффекты произошли. Какой-нибудь endpoint возвращает что-то, нужное вызывающему коду. А логирование нужно не вызывающему коду, а команде сопровождения, или аналитикам. Вот такая квитанция, которую невозможно получить иначе, как вызвав библиотеку логирования, является убедительным доказательством выполнения требуемого эффекта.
Квитанции можно упаковать в какую-то высокоуровневую структуру в качестве её элементов. Конструирование такой структуры невозможно без того, чтобы получить необходимые квитанции.
Обычно такие гарантии обеспечиваются покрытием тестами. Никак не могу придумать примера из жизни, где бы мне потребовался функционал из статьи.
Вызов функции, имеющей побочный эффект, и сам этот побочный эффект в общем случае никак не связаны. Из того, что вы вернули структуру. которая должна была быть сохранена в базу, не следует вообще никак, что она на самом деле была туда сохранена. Ну как минимум потому, что база не обязана ваши контракты соблюдать.
Мы разделяем приложение (прикладной уровень) и библиотеку. При реализации библиотеки мы пишем тесты и добиваемся того, что библиотека соблюдает свой контракт и квитанция возвращается только при условии исполнения эффекта.
При реализации приложения нам не нужны дополнительные тесты. Получив квитанцию, мы опираемся на обязательство библиотеки.
Почему бы не использовать понятное всем русское слово ЖУРНАЛИРОВАНИЕ вместо логирования?
Спасибо за статью. Как данный метод соотносится с обработкой исключений? Похоже, что при проверке, что операция прошла успешно, можно делать полагаясь на отсутствие исключений или на квитанции. В то же время кажется, что квитанции могут иметь и более широкое применение.
Насколько сильно захламляется реальный код при использовании этих фейковых квитанций?
В случае с IO (которая, очевидно, является тоже таким же фейком) цена вопроса - это всюду (где явно вывести не получится) расставить IO и заменить = на <-, грубо говоря.
То есть, "какая вам разница, программировать для монады Identity или монады IO..."
А как в случае с разнообразными квитанциями?
Судя по функции handle из статьи, даже игрушечный код начинает выглядеть ужасно.
Негативная коннотация в словах "захламляется", "фейк" ... Видимо, тяжёлый опыт?.. Могу только посочувствовать.
На практике квитанции объединяются в пакеты квитанций и не сильно обременяют код. Гарантии, которые получаются в результата - оказывают волшебное влияние на качество и снижение количества необходимых тестов.
Квитанции как способ отражения сделанной работы на уровне типов