ML
А что такое контекст дерева?
это некий env, который передается в поддерево. в реакте, кажись, на хуках работает
Size: a a a
2020 March 27
AN
Точно так же, как менеджат его бедные андроидеры. руками реконсайлишь пропсы этого компонента
Ну так о чем и речь. Тезис "все должно быть чисто и ректово" не работает.
Kd
хоть куда не ткни ифы от них можно избавится правильными средствами
прятание ифов в другом месте или замена на свичи это не избавление а маскировка
AN
это некий env, который передается в поддерево. в реакте, кажись, на хуках работает
Ну так нафига козе баян? Я лучше сделаю нормальный event pipe и прокину его везде.
ML
Ребят, пойдите разбейте на подстейты https://github.com/graphhopper/graphhopper но только так, чтобы кто-нибудь кроме вас мог потом понять, что там происходит.
Есом все что делает ваша программа - отображение джейсона на экране - то реакт очень хорош. Но не все программы такие.
Есом все что делает ваша программа - отображение джейсона на экране - то реакт очень хорош. Но не все программы такие.
а типа подход "раздробить всё на горстку классов" лучше даёт "кто-нибудь кроме вас мог пото понять, что там происходит"?
ML
ML
то что ты лично лучше знаком с каким то подходом, ещё не значит, что он объективно самый понятный
Kd
ооп самый понятный
AN
то что ты лично лучше знаком с каким то подходом, ещё не значит, что он объективно самый понятный
Indeed. Правда оно и в обратную сторону работает
ML
Ну так нафига козе баян? Я лучше сделаю нормальный event pipe и прокину его везде.
ну вот ты странненький. То "как его передавать? коллбеками что ли?" то "я и сам знаю, как нормально это сделать"
AN
ну вот ты странненький. То "как его передавать? коллбеками что ли?" то "я и сам знаю, как нормально это сделать"
На меня @angmarr наехал, сказал, что я опять ломаю чистое и прекрасное. Пытаюсь выяснить, как реальные пацаны предлагают
D
а типа подход "раздробить всё на горстку классов" лучше даёт "кто-нибудь кроме вас мог пото понять, что там происходит"?
Откуда такие гипотезы про меня? Я чаще вижу лишние выделения абстракций, чем недостаточное.
Все хорошо к месту и в меру. Не бывает подхода, который всегда и везде лучше. Вернее бывает, но это и так всем очевидно. Например понятные имена давать - правильно.
Все хорошо к месту и в меру. Не бывает подхода, который всегда и везде лучше. Вернее бывает, но это и так всем очевидно. Например понятные имена давать - правильно.
D
А вот эта иммутабельность головного мозга хороша в определенных кругах задач, не везде в программировании.
AK
Konstantin dmz9
ооп самый понятный
ну кстати, да. в него быстрее всего можно вкатится, в качестве пруфа этого - он самый популярный де факто. и любимимец бизнеса и промышленной разработки, потому-что позволяет стандартизировать подходы, архитектуру, менять людей словно винтики и быстро готовить новых. javaEE, .net и spring проекты тому подверждение.
VP
ну кстати, да. в него быстрее всего можно вкатится, в качестве пруфа этого - он самый популярный де факто. и любимимец бизнеса и промышленной разработки, потому-что позволяет стандартизировать подходы, архитектуру, менять людей словно винтики и быстро готовить новых. javaEE, .net и spring проекты тому подверждение.
Только там такой ООП, что просто набор процедур завёрнут в классы с всратыми именами
AK
Только там такой ООП, что просто набор процедур завёрнут в классы с всратыми именами
ну это тогда частный случай говнокода, хероту на любой парадигме можно сделать
AK
а есть в чятике адепты изначального ооп по кею? с передачей сообщений и акторными идеями?
AN
Только там такой ООП, что просто набор процедур завёрнут в классы с всратыми именами
ОП от ПП отличается идеологией. В ОП есть сущности, которые определяются набором поведений. Такая концепция действительно хорошо ложится на на нашу систему распознавания образов. Другое дело, что ОП - это широко. Например вполне может быть ОП без сложной системы наследования
AN
а есть в чятике адепты изначального ооп по кею? с передачей сообщений и акторными идеями?
Ну я бы сказал, что я скорее за. Хотя тут тоже не надо в крайности ударяться.
D
ну кстати, да. в него быстрее всего можно вкатится, в качестве пруфа этого - он самый популярный де факто. и любимимец бизнеса и промышленной разработки, потому-что позволяет стандартизировать подходы, архитектуру, менять людей словно винтики и быстро готовить новых. javaEE, .net и spring проекты тому подверждение.
Скорее это просто самый распространенный подход в то время, когда большенство текущих опытных разработчиков училось. Обьективно я не вижу больших преимуществ перед структурным программированием. Гошечка нифига не сложнее джавы ее, хотя там ооп не особо виднеется.