Так есть всегда можно дедовским фп методом - Reader и погнали. И ничего не надо прокидывать руками.

из коробки в дотнете же нет Ридера. то есть, это либо уМнЫй фреймворк, либо самописное решение. и в том, и в другом случае необходима достаточно высокая культура в команде.

Ридер пишется за 3 минуты с закрытыми глазами, чуть ли не самая простая вещь для реализации

Хаскель вообще простой на третий год изучения теорката.

а в чатике с Хаскелистами много знакомых слов для джава-разработчика?

а в си чатике?

а в чатике с Хаскелистами много знакомых слов для джава-разработчика?

удачи тебе с этими основами понять как сделать HTTP POST c треями ретраями. по крайней мере, я был в командах, где такие вещи просто вгоняли в ступор неподготовленных людей, из-за чего дальше протитипов Хаскель так и не пошел.

удачи тебе с этими основами понять как сделать HTTP POST c треями ретраями. по крайней мере, я был в командах, где такие вещи просто вгоняли в ступор неподготовленных людей, из-за чего дальше протитипов Хаскель так и не пошел.

А в чём проблема? В хаскеле это как раз проще всех остальных сделать. Ты попробуй на расте каком-нибудь, я посмотрю.

Чем это лучше прокидывания контейнера непонятно

статья выше довольно интересная, я даже попытался имплементировать в нашем проекте, но потом выпилил. потому что очень быстро IAppEnv превращается в помойку, в которой есть вообще все, и глядя на класс\функцию, которая его принимает вообще никак нельзя сказать, что именно из этого требуется, а что лишнее.

эпизод с коммивояжерами в пустыне - топ.

я пока только до арахнида-телепата досмотрел

серия крутая, хотя мне кажется, многие упустили суть)

Это ж и есть сервис локатор.

если эти функции имеют общую задачу, то почему зависимости туда прокидываются индивидуально? что будет, если я забуду прокинуть новые зависимости в какую-то из функций?

на моем опыте разным функциям обычно требуются разные зависимости. Да, некоторые из них пересекаются, но далеко не все

это все хорошо, когда ты сам себе клиент. сам написал функцию и сам ее заюзал

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

а какая альтернатива?

если эти функции имеют общую задачу, то почему зависимости туда прокидываются индивидуально? что будет, если я забуду прокинуть новые зависимости в какую-то из функций?

я пока не нашел. перечитываю статью уже в 15 раз, надеюсь, что может упустил какую-то деталь. подход кажется перспективным

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

ты по-моему не тот вопрос себе задаешь. функциональное программирование называется "функциональным" именно потому, что сакральным центром всего и вся является именно функция. родство между ними - не более, чем историческая случайность, как одинаковый цвет глаз у двух прохожих на улице. да, у них есть общий генетический код, но это еще не повод настаивать на их единстве. то же самое и тут: модули на самом деле - обыкновенный способ упорядочивать функции каким-либо образом; здравый смысл диктует разделение по принципу предназначения, но это потребность проистекает совсем из другого источника - от программиста, которому сложно удержать в голове происходящее. по ходу этого образа мыслей, нет ничего ни плохого, ни противоественного в том, что одно и то же необходимо для выполнения разных функций того же самого модуля.

у меня сейчас контекст маленький, но 1 на все приложение. Хотя это скорее потому, что у нас большая часть контекстов сделана в виде ажурных функций и уже изолирована друг от друга

я пока только до арахнида-телепата досмотрел

это очень большой вопрос, почему функциональное программирование называется функциональными. но тема не в этом. фпшечка в основной своей массе упирает на статические гарантии. модули как коллекции функций (в эфшарпе) статической гарантии связности функций не дают.

Их всем вразброс показывают. Нет четкого порядка серий.

так и в мире ООП нет гарантий, что то, что требуется условным конструктором, будет обладать внутренней связанностью и общим предназначением. это не проблема языка, это проблема решений программиста, который сам решает что такое "задача" и что такое ее "решение" с точностью до объектов или даже строчек кода.

теоретически я могу тоже обойтись одним контекстом на микросервис. но по мере роста проекта какие-то компоненты будут шариться между сервисами, поэтому хотелось бы найти компромисс между одним огромным контектом и контекстами на каждый случай

Ну, не вижу ничего смертельного в большом кол-ве контекстов. Уверен, ты сможешь найти компромисс, по крайней мере во вменяемой скотобазе, над которой у тебя есть контроль

в мире ооп у меня есть гарантия, что ты не сможешь взять себе в зависимости один метод из класса. в мире ооп принцип "все или ничего" (на уровне класса)

в мире ооп у меня есть гарантия, что ты не сможешь взять себе в зависимости один метод из класса. в мире ооп принцип "все или ничего" (на уровне класса)

у меня цель писать поменьше кода. если мне надо на каждый слой создавать по два интерфейса "просто потому", то я лучше буду прокидывать через конструкторы

ну вот вам пример. допустим, я логически скомпоновал свои функции в модуль, предположим они обслуживают одну конкретную цель, скажем, е-коммерс заказы, не суть. и вот есть этот модуль, весь из себя стройный, документированный, покрытый тестами. и есть мой коллега, тоже вроде не дурак, который сидит такой и "оу, вот прикольная функция по поиску и вот еще одна по сохранению в бд, дай-ка я их заюзаю, чтоб свои не писать"

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

залил в мастер публчиную функцию - отвечай за бэквард компатибилити, все простор.