Да, разумеется.

Давай не будем "да ты - да я". Может это и так, не стану спорить. Однако ООП от этого не станет меньшае походить на копипасту.

Это плохая практика, не изобретать велосипедов. И твоё глобальное заблуждение меня не волнует тоже.

Дак а я про что? Если я не могу выбрать то, что мне нужно, я пишу это сам. А не ковыляю в кроссовках на шпильках.

Если твиг еще и почту отправлял бы, это были бы кроссовки, жаренные с трюфелями.

А вот давай теперь посмотрим на Смарти внимательно. Допустим я юзаю фреймворк. К примеру Yii. В нем есть вполне достойный конструктор форм. С валидацией, блэкджеком и шлюхами. И мне нужно сделать несколько чекбоксов. Но я, наслушавшись твоих советов, решил, что нужно юзать "золотой стандарт", и прикрутил Смарти. А там тоже есть {html_checkboxes}, (тот самый, который глючит ). И как теперь быть? Нужно ли объяснять, что налицо Boat anchor? И это в лучшем случае. А если теперь кто-то из команды будет юзать генератор Yii, а кому то захочется воспользоваться медвежьей любезно предоставленной услугой Смарти? Начинается каша. Какой это антипаттерн? Или все ещё "золотой стандарт"?

А еще, как в таком случае быть с SOLID? С тем самым DIP? Если генерация элемента находится в шаблоне, значит абстракция начинает зависеть от деталей.
Как быть с переиспользованием? Я захочу другой шаблонизатор, или вообще натив. Где чекбокс с его аттрибутами и возвратом? Нету.

А всё потому, что к кросовку прибили каблук. Генерация элементов, это не профильная задача шаблонизатора. Равно как и многое другое, не только из набора {html_}. Про кэширование даже говорить не стоит, кроме него очень много разных "веселых" моментов. Массивы, одних модификаторов около 20 штук, даже собственный eval есть и так далее. Вот не слишком ли много она на себя берет? Профильная задача шаблонизатора - заполнить данными и отрендерить шаблон. Всё. Остальное от лукавого.

Да, это не то. И я поэтому и не выбрал Смарти. Мне это не подходит. Тебе подходит - радуйся. А мне нет. Мне бы подошел XTemplate, очень лаконичный и простой шаблонизатор. Но у него нет наследования шаблонов. А это как раз профильная задача. Так что тут наилучшее решение - собственный велосипед. Что я и сделал. И никакие твои абстрактные инсенуации меня не ипут.

Вообще это относилось к этому:

Ты не прав. Сможет. И это я там и обосновал.

Занимает, не спорю. Ну и что? Toyota тоже занимает лидирующую позицию по количеству произведенных машин. Однако это не значит, что Ламборджини хуже. Да и моя Volvo сто вперед даст "одноклассникам" от Тойоты. Хотя их совсем немного производится. Популярность еще не признак качества.

Популярно, о чем речь. Я сам нет-нет, да и да. Но только если это решение действительно подходит. Хотя бы на 90%. Но зачастую это не так, потому что у "готовых наработок" очень часто встречается болезнь "бесконечное улучшение". А это порочная практика, потому что когда вроде все хорошо, улучшать больше некуда, начинается выдумывание проблем и их героическое решение. Как в примере со Смарти. Наворотили бог весть чего, теперь не поймешь, шаблонизатор это, или язык программирования. Ну и DIP естественно. Часто либы не подходят по "идейным" соображениям. Ну не встают ровно. А подгонять абстракцию под детали, это ли не антипаттерн?

Никакой связи не улавливаю. Что, до композера значит эти бест-практики не использовались? Или на гитхабе только лучшие практики?

Мне он вообще побоку, зачем мне от него зависеть. Я говорил, что у него очень много зависимостей.

Однако вот что интересно. Почему то PSR7 они реализовали собственный. Хотя на 100% знали, что есть разработка от автора. Куда еще авторитетнее. Вот тебе и "золотой стандарт". Это велосипед чистой воды.

А я тебе скажу почему, так как я досконально изучил обе реализации. Потому что у них немного разная специфика. И здесь Slim соблюдает DIP из SOLID. Наплевав на твои "золотые стандарты" и антипаттерны. Это для них удобнее и оптимальнее, чем костылять над готовым решением от O'Phinney. Это одна из основных функциональностей фреймворка, тут прикостыливать чужие решения себе дороже.

Я вот тоже сделал свой, который удобен мне. И не потому, что считаю себя умнее их обоих. А потому, что сделал с учетом своей специфики. Немного изменив архитектуру, взяв из этих двух все самое лучшее, и добавив своего. И этим горд, и доволен как слон. Плюс профитом то, что я теперь досконально знаю этот предмет. Изнутри, до каждого метода PSR-интерфейсов.

А ты продолжай в своем духе: проксирование, декорирование, адаптеры и прочие костыли.

Только не смущай молодежь. Велосипеды, это хорошо. Вон выше тебе пример обратной стороны "суровой реальности" - Arh. И таких много. Если у тебя вокруг все так плохо, ну что ж... Сочуствую. Сходи, свечку что ли поставь.

История не стоит на месте. Посмотри на тот же PHP. Да, от версии к версии ООП в нем улучшалось, спору нет. Однако и инструменты для ФП тоже развиваются. Тип callable, замыкания, функтор, анонимные функции и так далее, это все прерогатива функциональщиков. Я не говорю уже про другие ЯП, допустим чисто функциональный Haskell или Lisp. Там твоим ООП и не пахнет, однако на них пишут такие мэтры, как Хаскел Кaрри (основатель), Пейтон Джонс, Филип Вадлер и другие, которых ты не сможешь упрекнуть, что они не ровня Бобу Мартину.

Причем тут я? Просто у нас разные кумиры. И мои кумиры, мягко скажем, не совсем разделяют точку зрения твоих. Но я же не говорю, что это "золотой дождь стандарт". Я говорю - это альтернативный подход. Который тоже имеет право на жизнь, и часто приносит гораздо больший профит. Не всегда, согласен. Если вокруг "суровая действительность", придется прогибаться. Но я твердо убежден, что человек сам хозяин своей судьбы, и не стоит так низко ценить себя. Хотя зависит от характера. Если тебе по жизни удобно быть ведомым, конечно лидерство и самостоятельные решения будет для тебя плохой практикой. Тогда это оправдано.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.