которые сорок раз return пишут в Хаскеле чтоб подняться на урвоень IO

def splitErrors[ T[_]: Traverse: Alternative, F[_]: Functor, G[_]: Applicative, E, A](ls: T[F[A]])( implicit errors: ErrorsTo[F, G, E] ): G[(T[E], T[A])] = ls.traverse(_.attemptTo[G, E]).map(_.partitionEither(identity)) def parseInt[F[_]: Applicative: Raise[*[_], String]](s: String): F[Int] = s.toIntOption.orRaise(s"could not parse $s") type Calc[A] = EitherT[Eval, String, A] splitErrors[Vector, Calc, Eval, String, Int]( Vector("1", "hello", "2", "world", "3").map(parseInt[Calc]) ).value

с сайта тофу - простой пример как распарсить инт!

простой же

всё понятно

чо тут непонятного

пиздец

Нижников, канеш, сильно дохуя умный, но долбоеб

долбоёб, да

Его бы энергию да в мирное русло

Ну он очарован математикой

и все таки блять - как вы логгируете в своих ЭфШарпах? просто принимаете логгер параметром?

и все таки блять - как вы логгируете в своих ЭфШарпах? просто принимаете логгер параметром?

Log.tracef ....

Например

и все таки блять - как вы логгируете в своих ЭфШарпах? просто принимаете логгер параметром?

Да.

Тупо ссылка на модуль

и все таки блять - как вы логгируете в своих ЭфШарпах? просто принимаете логгер параметром?

Или статичный класс или явно ILogger через DI

статичный класс может быть модулем, да

Тупо ссылка на модуль

Я так делал, а потом начал разделять логгеры по функциональности, и пришлось всё-таки через параметры передавать.

ну я так и думал, да. но в итоге все равно приедтся через DI

так что наверно лучше сразу

У меня там логи от телеграма в одну папочку валятся, а от XMPP в другую, очень удобно.

У меня там логи от телеграма в одну папочку валятся, а от XMPP в другую, очень удобно.

В каком-нибудь серилоге же можно через конфигурацию синков настроить, в аппсеттингсе

можно ещё так module MyBusinessLogic = private static let logger = NLog(Serilog).create “MyBusinessLogic”

В каком-нибудь серилоге же можно через конфигурацию синков настроить, в аппсеттингсе

Ну я и настроил

ну то есть по месту создать статичный инстанс и хуй забить

А логировать всё через один статический логгер

В каком-нибудь серилоге же можно через конфигурацию синков настроить, в аппсеттингсе

https://github.com/codingteam/emulsion/blob/8e1d410502d79f7a6a915147d17edd6e62d824e0/Emulsion/Logging.fs#L24-L25

Да, понял

А логировать всё через один статический логгер

А как он будет понимать, что в какую категорию складывать?

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

Не, там "я пошёл отсюда", но так можно только к младшему или близкому другу. Ещё я бы убрала местоимение и "отсюда", а глагол из будущего времени поставила бы в настоящее 🤔 будет просто "ухожу". То, что уходишь именно ты, и отсюда - подразумевается и так

Ага, типа «пошёл ты»?

Я устал, я ухожу!

Я устал, я ухожу!

ну да, ты уже старый, тебе б на покой

Тебе ж наверное уже за 30, а там жизни нет

А как он будет понимать, что в какую категорию складывать?

Log.Logger1, Log.Logger2

Log.Logger1, Log.Logger2

Ок, да, так можно :)

я в пульсаре логаю правда все в один логгер, слишком удобно)

но наверное есть кейсы когда в разные логгеры нужно

я в пульсаре логаю правда все в один логгер, слишком удобно)

тоже пробрасываешь параметр как DI?

нет, как статическое мутабл поле

т.е. юзер пишет Pulsar.Logger <- his logger

а я везде юзаю его через Log.Logger

Статическое мутабл поле - лучший DI

На самом деле

Статическое мутабл поле - лучший DI

чорт, я же недавно спрашивал про это и я все удалил

Статическое мутабл поле - лучший DI

нет

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

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

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

А когда ты пишешь DI, подразумеваешь контейнер или руками прикидывать нужные параметры при вызове фций?

@atsapura , код кидай, поглядим, зададим вопросы

А когда ты пишешь DI, подразумеваешь контейнер или руками прикидывать нужные параметры при вызове фций?

Ну у нас это собирается под одним интерфейсом IAppEnv. При желании, для него можно сделать дробление типа IMasterDb, IPaymentGateWay etc., а сам IAppEnv заставить наследовать все это. А дальше в функцию, где тебе это нужно, ты прокидываешь первым параметром либо IAppEnv целиком, либо IMasterDb, если датабазы достаточно. IMasterDb у нас имеет методы вида GetProductItem: string -> Async<ProductItem option>.

Благодаря object expressions такие интерфейсы можно налету заимплементить в вашем AppEnv, что мы и делаем у себя)

Ну у нас это собирается под одним интерфейсом IAppEnv. При желании, для него можно сделать дробление типа IMasterDb, IPaymentGateWay etc., а сам IAppEnv заставить наследовать все это. А дальше в функцию, где тебе это нужно, ты прокидываешь первым параметром либо IAppEnv целиком, либо IMasterDb, если датабазы достаточно. IMasterDb у нас имеет методы вида GetProductItem: string -> Async<ProductItem option>.

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

@atsapura , код кидай, поглядим, зададим вопросы

Я уточню, не нарушает ли это наш NDA, и если все ок, выложу семплы

Я уточню, не нарушает ли это наш NDA, и если все ок, выложу семплы

Код без контекста может нарушать NDA ?

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

как я сказал, если нужна гранулярность, ее легко сделать. И будешь прокидывать не целиком энв, а ILog, у которого будет проперти ILogger

а твой IAppEnv будет наследоваться от этого ILog, и будет наружу выставлять Ilogger свой

твоя же функция ничего об этом знать не будет, она будет принимать параметр log: #ILog

удобнее всего когда прокидывать не надо ничего) я бы сказал что логгер это исключение

удобнее всего когда прокидывать не надо ничего) я бы сказал что логгер это исключение

т.е. хардкодить все зависимости или что?

я так понял речь о https://bartoszsypytkowski.com/dealing-with-complex-dependency-injection-in-f/ там и код можно глянуть

я так понял речь о https://bartoszsypytkowski.com/dealing-with-complex-dependency-injection-in-f/ там и код можно глянуть

Да, идея спизжена оттуда. Мы у себя ее использовали не в чистом виде, а чуток подтюнили под свои нужды. Но сутенька оттуда

т.е. хардкодить все зависимости или что?

Не вижу особо ничего криминального

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

с другой стороны, тривиальные случаи нередко вырастают со временем в мясо, а тестируемость туда никто не добавляет)

@omgszer а каким гит клиентом на маке пользуешься?

Я помню, он говорил, что fork

Ну у нас это собирается под одним интерфейсом IAppEnv. При желании, для него можно сделать дробление типа IMasterDb, IPaymentGateWay etc., а сам IAppEnv заставить наследовать все это. А дальше в функцию, где тебе это нужно, ты прокидываешь первым параметром либо IAppEnv целиком, либо IMasterDb, если датабазы достаточно. IMasterDb у нас имеет методы вида GetProductItem: string -> Async<ProductItem option>.

Звучит как зио

Звучит как зио

это хорошо или плохо?

Хз

Я не знаток дырок в скале

@omgszer а каким гит клиентом на маке пользуешься?

Fork

ну тут никаких дырок нет

Обычный composition root который сам собираешь

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

Или обжект локатора статичного

Или как его там

сервис локатор это зло