Сделай пр, покажи, как надо делать!
сперва добейся?
Shub
Shub
самого-то весь этот бойлерплейт не смущает?
Shub
минвайл, зарисовки с натуры
Shub
https://stackoverflow.com/questions/31003013/directory-createdirectory-not-exists-in-net-core
Shub
не жили богато - нехер начинать ©
Ilya
2015 год же🤔
Roman
Vasily
Дабы быть объективным, createdirectory есть
Vladislav
https://twitter.com/stevensanderson/status/1140556253724336128?s=12
Doge
самого-то весь этот бойлерплейт не смущает?
По хорошему этот бойлерплейт должен быть на самом низком уровне: там где непосредственный доступ к БД, сетям и внешнему миру.
А всё выше уже должно через него выражаться. Тогда можно будет один раз его написать и трогать только в исключительных ситуациях.
Я как раз пару лет назад писал пет на скале через фри монады примерно в таком стиле, получилось в принципе вполне нормально.
Vasily
Разобрался я во вчерашней херне с эвентами
Vasily
Оказалось, использование Event.map очень плохая идея
Vasily
Короче
Vasily
Есть у меня async
Vasily
Который ожидает , что придет эвент
Vasily
И есть некий callback, который результат процессит
Vasily
Дык вот, если делать Event.map, создается неявный делегат, который потом хер удалишь
Vasily
А если делать после ожидания эвента Async.map callback для нужного результата, то все ок
Vladislav
Дык вот, если делать Event.map, создается неявный делегат, который потом хер удалишь
map -> await event?
Ayrat
Интересно.
Vasily
Но в целом, сука, логично
Vasily
Короче, не используйте Event.map
Ayrat
Я вчера посмотрел код евейт еаента, там все ок вроде
Vasily
В Await все ок, да
Ayrat
Там создаётся свой внутренний делегат
Vasily
Там создается делегат, который потом делает отписку
Vasily
В Event.map все не так хорошо
Vasily
Т.е. если его использовать, то надо использовать один раз
Ayrat
Зонятно
Vasily
Второй раз на тот же колбэк создаст еще один обработчик
Ayrat
Ишуй тут не поможет, кстати.
Vasily
Не поможет
Ayrat
Так как делегаты сидят внутри и наружу не выдаются, хер ты замапишь тот же делегат
Vasily
Помогает такое:
let! evt=serverDhParamsEvt|>Async.AwaitEvent|>Async.StartChild
Channel.sendRaw(serialize dhParams|>wrap)
let! res=evt|>Async.map(processDhParams nonces)
Ayrat
Я когда нибудь привыкну к тому, что ты ставишь пробелы только там, где требует компилятор
Vasily
Я когда нибудь привыкну к тому, что ты ставишь пробелы только там, где требует компилятор
Когда-нибудь безусловно привыкнешь
Vladislav
Doge
Когда-нибудь безусловно привыкнешь
А зачем брать язык с прекраснейщим ML синтаксисом и портить эту красоту таким стилем написания?
Vasily
А зачем брать язык с прекраснейщим ML синтаксисом и портить эту красоту таким стилем написания?
Pfvtxfybz r cnbk. ghbybvf.ncz
Vasily
Замечания к стилю принимаются
Vasily
Поскольку лично я пока не пришел к выводу, что пишу в правильном стиле, it is subject to change
Doge
Замечания к стилю принимаются
Ну смущает именно что отсутствие пробелов между операторами и операндами.
Имхо, так читать сложнее, код превращается в единую строку без выделенных частей. А человеческий мозг обычно привык как раз к тому, что отдельные слова выделяются пробелом, переводом строк и т.п.
Vasily
Ок, попробую ставить больше пробелов
Vasily
Хотя это где-то в настройках нужно
Vasily
Конкретно мне
Vladislav
детерминированного автоформата не хватает
Vladislav
нажал форматнуть и отправил код в вальгаллу
Vasily
Лично мне не хватает автопроблеов между операторами
Крылатый
Не, фу, ужасный стиль.
Крылатый
Нечитаемо вообще.
Doge
Ок, попробую ставить больше пробелов
Если я правильно распарсил исходный кусок, то я бы сделал что-то вроде такого, но это опять-таки полное имхо, т.к. стиль во многих вещах это личное дело конкретной команды.
let act = Channel.sendRaw (serialize dhParams |> wrap)
let! evt = serverDhParamsEvt
|> Async.AwaitEvent
|> Async.StartChild act
let! res = evt
|> Async.map (processDhParams nonces)
Vasily
Doge
Да, правильно. НО. Я экономлю строчки
А зачем ты это делаешь стилем?
Это надо делать рефакторингом, грамотным проектированием и делением на модули, классы, методы, функции и т.п.
Крылатый
Расстреливали из рогаток.
Vasily
У нас в детстве детвора забивала камнями за отсутствие пробелов.
Судя по тому, что ты выжил, ты был как все
Крылатый
Я был лучше.
Крылатый
Я задавал правила стиля.
Vasily
О, точно
Romɑn
@vshapenko в общем, я таки доупарывался с интепретатором. И вот результат:
дерево исполнения:
https://github.com/atsapura/CardManagement/blob/interpreter/CardManagement/CardWorkflow.fs
интерпретатор, внедряющий зависимости:
https://github.com/atsapura/CardManagement/blob/interpreter/CardManagement.Infrastructure/Interpreter.fs
https://github.com/atsapura/CardManagement/blob/interpreter/CardManagement.Infrastructure/Interpreter.fs#L40
getMongo вызывается каждый раз
мб его можно зависимостью прокинуть?
Vasily
Всякие logify смущают, но пока неясно, что с ними делать
Vasily
В CardWorkflow чистый free monad прям
Vasily
@atsapura по идее подобные простынки async {
let! maybeUser = getUserAsync mongoDb id
return! maybeUser |> next |> interpretCardProgram
} можно переписать как getUserAsync mongoDb id |>Async.map (next»interpretCardProgram) попробовать
Roman
Roman
Vasily
И даже вынести let nextop=next»interpretCardProgram
Vasily
Да, вижу
Vasily
В теории, часть бойлерплейта с логированием можно вынести в Combine
Roman
Чет его много
не хотел размазывать по всем слоям логи, нашел только такой выход. Если есть идеи, как улучшить — буду рад!