- Да ладно, всё у PHP нормально со сборкой мусора уже лет 10 как. Проблема в программистах на PHP, которые привыкли, что он «умирает»
@Proger_XP Я в данном вопросе не эксперт, просто читаю про то, как люди используют «демонов» на PHP, например ReactPHP, и таки сталкиваются с трудностями.
Про привычки программистов не поспоришь. А так как и Laravel, и сторонние компоненты для него пишутся в первую очередь для веб, то и надеяться особо не на что :)
ИМХО, совершенно недопустимо изменять данные в Представлении. У кого-то может возникнуть такой соблазн, типа, для "оптимизации". Счётчик какой-нибудь посчитать и сохранить. Но не надо так делать! Потому что это портит логику и усложняет сопровождение.
Что же до "обращения к базе" в смысле операций чтения, в идеале да, они должны все происходить до обращения к Представлению. Но мы же сами добиваемся абстракции, когда чтение свойства объекта может неявно сопровождаться каким-то действием. Представление понятия не имеет делали мы eager loading или нет. Оно просто использует объект. Короче, врядли удастся избежать select в 100% случаев. По причине именно "объектности", "принципа чёрного ящика". Мы…
Спасибо за интерес, @nailfor
В теме очередей есть множество нюансов и особых случаев. Однако суть этой конкретной статьи в том, чтобы показать область применения и облегчить старт. Пример хорош пока он прост и сфокусирован.
Это верно, но меня напряг твой исходный тезис, что «[сам] PHP ещё неидеально подходит [...]» — все же это не так. Об этом и написал.
В частности, из верной предпосылки можно вывести следствие, что если наблюдаются утечки — достаточно переписать часть кода на голом PHP, чтобы их избежать. (А из неверной — что нужно все срочно переписывать на Python или, там, на Node.js. Да, я видел такое.)
Но, вообще, к теме статьи (очередям) это имеет мало отношения, потому что, как ты тут же и пишешь — скрипт все равно нужно регулярно перезапускать из-за изменения кода, и проще всего не каждую задачу обрабатывать в цикле внутри PHP, а иметь внешний цикл (bash, cron, supervisord, systemd, etc.), который будет запускать PHP «с нуля» для обработки только одной задачи. В этом случае утечки не страшны.