ŹR
Это, типа, функции в стракте как поля пишутся?
Это было бы слишком жостко
Size: a a a
2020 October 06
DF
А, это для мутации стейта отдельный модуль.
ŹR
Я как-то пытался намутить ООП на лямбдах в эликсире, но почему-то недоделал - не помню уже почему
SM
Вот это самая тырпрайз тема. Думаю, в идеале так и надо писать
Не, про самую тырпрайз тему я прочитал не помню где. Делаем короч для каждого традиционного генсервера 4 модуля: Thingy, Thingy.Server, Thingy.State, Thingy.Impl.
Но это немного перебор, наверно.
Thingy содержит публичное API (в основном, это вызовы GenServer.call(Thingy.Server, ...) и иже с ними)Thingy.Server - это непосредственно генсервер, он содержит только колбэки и вызывает Thingy.Impl
Thingy.Impl содержит всю бизнес-логику генсервера; он же вызывает Thingy.State для изменения стейта.Но это немного перебор, наверно.
LL
Я как-то пытался намутить ООП на лямбдах в эликсире, но почему-то недоделал - не помню уже почему
Потому что это бесполезно?)
И в замыкания стейт нельзя поменять, кстати
И в замыкания стейт нельзя поменять, кстати
DF
Читать стектрейсы такого ООП будет тем ещё удовольствием.
DF
fun на fun через fun.
ŹR
Потому что это бесполезно?)
И в замыкания стейт нельзя поменять, кстати
И в замыкания стейт нельзя поменять, кстати
Да, нельзя. Да, бесполезно. Но недоделал почему-то по другому Ж)
AL
Не, про самую тырпрайз тему я прочитал не помню где. Делаем короч для каждого традиционного генсервера 4 модуля: Thingy, Thingy.Server, Thingy.State, Thingy.Impl.
Но это немного перебор, наверно.
Thingy содержит публичное API (в основном, это вызовы GenServer.call(Thingy.Server, ...) и иже с ними)Thingy.Server - это непосредственно генсервер, он содержит только колбэки и вызывает Thingy.Impl
Thingy.Impl содержит всю бизнес-логику генсервера; он же вызывает Thingy.State для изменения стейта.Но это немного перебор, наверно.
если код развесистый, разделить определённо имеет смысл, и по такой схеме вполне нормально, кажется, должно быть, вай нот
AL
а если генсервер пару параметров в стейте хранит, по одному handle_info/handle_call да пару функций для работы - ну, такое я бы не стал дробить точно
SM
если код развесистый, разделить определённо имеет смысл, и по такой схеме вполне нормально, кажется, должно быть, вай нот
В отдельных случаях это может быть полезно, но в большинстве будет оверкил
AL
именно
DF
Непонятно зачем разделять Server и Impl.
DF
Если всё что делает Server — это вызовы Impl.
AL
чтобы имплементацию менять? навроде DI?
AL
но я точно не знаю, только предполагаю
DF
Что, в рантайме прям?
AL
не, скорее при компиляции определять в зависимости от чего-либо (настроек окружения)
RK
Непонятно зачем разделять Server и Impl.
Чтобы отделить delivery layer (server) от слоя с логикой?
DF
А зачем?