Вполне помогут. Несмотря на то, что основной вал хайпа по микросервисам прошел, все равно многие серьезные проекты дрейфуют в сторону развертывания отдельных сервисов в k8s, и вот там без асинхронного рантайма приходится очень туго: банально невозможно реализовать health checks, работающие адекватно.
Если асинхронный код на PHP уже никого не удивляет и активно используется в проде, то многопоточный — пока все еще большая экзотика, требующая немало потрудиться.
Ну и фреймворкам типа Symfony/Laravel/Laminas ничто не помешает подтянуться, выкатив скелет асинхронного сервиса.
Не, я согласен, что фишка удобная. Но опять-таки на данный момент статический контроль «генерикообразных» структур возможен через Psalm. Имхо, отсутствие генериков — не самая главная беда PHP. На мой взгляд, куда больше вредит отсутствие нормальной многопоточности. Судя по всему, мы рискуем увидеть fibers уже в 8.1, а там и многопоточные рантаймы подтянутся под Amp/ReactPHP. В интересное время живем, хе-хе.
Это вы приписываете разработчику мысль о том, что каждый потребитель должен окупить его расходы. В реальном мире такого нигде не наблюдается, кроме случаев, когда заказчик заказывает разработчику уникальную программу; в этом случае он платит упомянутые вами Y денег.
Во всех других случаях стоимость продукта Y/N денег, где N — некая оценка минимального числа пользователей, которые купят копию. По сути вы утверждаете: «почему вы считаете, что вам должны платить Y? Получите Y/N и расслабьтесь!»
Как-то вы странно Маркса прочитали. Дело в том, что очень мало кто может купить программу, оплатив труд программиста. Программа пишется иногда несколько лет, программист за это время заработал десятки тысяч долларов, но программа стоит, к примеру, всего сто долларов. Почему? Потому что продаётся множество её копий, за счёт этого каждую копию можно купить дешевле.
Именно поэтому, например, ваш мобильник, продукт сложнейших технологий, стоит сотни, а не миллионы долларов. Потому что в разработку технологии вложились один раз, а изготовление копий обходится намного дешевле, чем разработка.
И, кстати, лишнее доказательство того, что наличие шаблонизатора не отменяет необходимости думать. Ночной кошмар можно с равным успехом претворить в жизнь и на похапе, и на Смарти.
Ещё как нужны, причём именно наследуемые. Игра с внешним видом — это же основы маркетинга! В интернет-магазинах бывают различные акции и «сезоны скидок», бывают различные рекламные кампании — всё это требует оперативного переключения внешнего вида сайта (и, что ещё важнее — оперативной разработки оного!) Не следует понимать «скин» исключительно как возможность «поменять в личных настройках цвет форума с синенького на зелененький».
Пожалуй, таки да, предвзято относитесь :) Но проблема действительно сложная. Хоть шаблон и программа, но способа добиться внятного полиморфизма от этой программы в общем-то нет…
Такой подход губителен в крупных проектах. Написание скинов превращается в кровавую оргию с копипастом. Да и в небольших проектах аккуратное точечное применение фрагментации позволяет упростить жизнь.
Вы про {php}? Там же его запретить можно, что и надо делать первым делом. А исполняемый код пусть в плагинах живет.
Другое дело, что интеграция с фреймворками идёт гладко ровно до тех пор, пока работа шаблона ограничивается выводом переменных. Как только идём дальше (например, хотим использовать хелпер url в ZF для генерации URL) — начинается адский оверхед, каждому хелперу нужен прокси-плагин.
Шаблнизаторы — не панацея. Я много лет работал со Smarty и другими шаблонизаторами, потом вернулся к нативной шаблонизации. Не хотелось бы начинать холивар ради холивара, есть преимущества у обоих подходов, в том числе и множество преимуществ у нативной шаблонизации. Единственный безусловный минус — verbosity, это действительно раздражает.
Забавно, у меня имел место обратный процесс :) Я много лет был апологетом Smarty, а сейчас предпочитаю обходиться без него, а в качестве плюшек — ZF-овские view helpers. Да, синтаксис не слишком удобный, но зато на порядок меньше оверхеда при большей гибкости. Шаблонизатор отлично изолирует логику представления, но я в какой-то момент поймал себя на том, что зачастую эта изоляция дороговато обходится. Например, внедрять все хелперы в Smarty в качестве плагинов — дикий головняк, практической пользы от которого очень мало, если не отдавать проект на растерзание заведомым говнокодерам.
Насчёт 1.4 — тут такая фишка: шаблон — это тоже программа. Даже голый HTML является программой отображения страницы в браузере. В шаблонах голый HTML разбавлен дополнительными инструкциями, формирующими — сюрприз! — логику представления. Естественно, эта логика решает задачи типа «вывести в таблице список значений», а не делает SQL-запросы к базе. PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
Для интеграции несовместимых интерфейсов существует паттерн "Адаптер". А объект-логгер должен быть контейнером для объектов-адаптеров с обобщенным интерфейсом. Даже в отсутствие конфликта интерфейсов нормальный проектировщик поступит именно так в целях масштабируемости. «Минимизация количества классов» — не та цель, за которую стоит воевать. Классов должно быть столько, сколько необходимо для реализации грамотной архитектуры.
Я считаю, что если возникает проблема «конфликтующих интерфейсов», то это явный результат грязных хаков и плохой архитектуры.
Задачи, где «старое доброе процедурное программирование» действительно (а не по причине плохого знания ООП разработчиком) эффективнее ООП, редки и нетривиальны, если речь, конечно, не о helloworld'ах и не о простых скриптах на коленке, в которых время решения непосредственно кореллирует с количеством набранных символов.
Единственная здравая мысль — про шаблонизацию родными средствами PHP, остальное представляет собой смесь словоблудия и «вредных советов».
Если асинхронный код на PHP уже никого не удивляет и активно используется в проде, то многопоточный — пока все еще большая экзотика, требующая немало потрудиться.
Ну и фреймворкам типа Symfony/Laravel/Laminas ничто не помешает подтянуться, выкатив скелет асинхронного сервиса.
Во всех других случаях стоимость продукта Y/N денег, где N — некая оценка минимального числа пользователей, которые купят копию. По сути вы утверждаете: «почему вы считаете, что вам должны платить Y? Получите Y/N и расслабьтесь!»
Именно поэтому, например, ваш мобильник, продукт сложнейших технологий, стоит сотни, а не миллионы долларов. Потому что в разработку технологии вложились один раз, а изготовление копий обходится намного дешевле, чем разработка.
Имхо такой девайс имеет смысл только для тех, у кого действительно постоянный поток винтов под уничтожение.
Код есть код, его дублирование всегда порождало и будет порождать проблемы. Точно так же, как и тотальное наследование всего и вся, впрочем.
Пожалуй, таки да, предвзято относитесь :) Но проблема действительно сложная. Хоть шаблон и программа, но способа добиться внятного полиморфизма от этой программы в общем-то нет…
Другое дело, что интеграция с фреймворками идёт гладко ровно до тех пор, пока работа шаблона ограничивается выводом переменных. Как только идём дальше (например, хотим использовать хелпер url в ZF для генерации URL) — начинается адский оверхед, каждому хелперу нужен прокси-плагин.
Насчёт 1.4 — тут такая фишка: шаблон — это тоже программа. Даже голый HTML является программой отображения страницы в браузере. В шаблонах голый HTML разбавлен дополнительными инструкциями, формирующими — сюрприз! — логику представления. Естественно, эта логика решает задачи типа «вывести в таблице список значений», а не делает SQL-запросы к базе. PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
Я считаю, что если возникает проблема «конфликтующих интерфейсов», то это явный результат грязных хаков и плохой архитектуры.
Единственная здравая мысль — про шаблонизацию родными средствами PHP, остальное представляет собой смесь словоблудия и «вредных советов».