V
Борщевик Ёбаный
проектирование через ООП это какой-то неправильный путь?
Правильный, если ты любишь не только бананы, но и горилл
Size: a a a
2021 January 06
БЁ
очень абстрактно.
БЁ
я просто поймал себя на мысли, что 90% макросов, которые когда-либо писал на эликсире
это я переизобрёл классы тупо
это я переизобрёл классы тупо
БЁ
иначе код совсем в хлам превращается, и макросами его получается неплохо задраить
только в итоге получаются классы
только в итоге получаются классы
БЁ
не глубокое ооп, просто макрос это abstract class
каждый модуль, который его подключает через use становится тупо наследником
с помощью dsl переизобретает переопределение полей, да и defoverridable туда же
каждый модуль, который его подключает через use становится тупо наследником
с помощью dsl переизобретает переопределение полей, да и defoverridable туда же
БЁ
у всех же так?
PR
Вы прям по антипаттернам из книжек по элексиру все сделали.
БЁ
я прочитал вроде бы все
БЁ
не понимаю, про какие антипаттерны речь
AB
V
Небось через ООП всё делали?
ООП там особого не было, поначалу там ничего такой ddd-like код был, а дальше ребята начали удлинять fsm в разные стороны, и вот тут всё пошло не так.
AB
Борщевик Ёбаный
не глубокое ооп, просто макрос это abstract class
каждый модуль, который его подключает через use становится тупо наследником
с помощью dsl переизобретает переопределение полей, да и defoverridable туда же
каждый модуль, который его подключает через use становится тупо наследником
с помощью dsl переизобретает переопределение полей, да и defoverridable туда же
Это типа как use genserver?
V
Борщевик Ёбаный
очень абстрактно.
https://clojure.org/about/state
There is no way to obtain the state independent of the identity other than copying it. There is no way to observe a stable state (even to copy it) without blocking others from changing it. There is no way to associate the identity’s state with a different value other than in-place memory mutation. In other words, typical OO has imperative programming baked into it! OO doesn’t have to be this way, but, usually, it is (Java/C++/Python/Ruby etc).
PR
defoverridable, макросы там где не неужно, использование акторов как классов. Но это я так вижу по скудным данным, может быть не все так. Я плохо понимаю как DRY вообще с OOP связан.
БЁ
V
https://clojure.org/about/state
There is no way to obtain the state independent of the identity other than copying it. There is no way to observe a stable state (even to copy it) without blocking others from changing it. There is no way to associate the identity’s state with a different value other than in-place memory mutation. In other words, typical OO has imperative programming baked into it! OO doesn’t have to be this way, but, usually, it is (Java/C++/Python/Ruby etc).
вы почему-то примешиваете мутабельность к ооп
БЁ
отлично можно вывозить на иммутабельных классах, где изменение класса это копия
БЁ
без сеттеров
БЁ
но просто иметь классы как инструмент для проектирования
V
ну это классическое понимание ооп: классы - это прототипы инстансов. дальше что?
БЁ
а дальше идём работать!
AI
Fsm как модель описания некого процесса в коде очень теряет читабельность по мере усложнения процесса.
ну их можно друг в друга вкладывать, в gen_statem даже поддержку для этого говна вон добавили