Если говорить о классах собственного проекта, то еще куда

не шло. Но если о библиотеках или фреймворке, где мне нужно что-то изменить для себя? Или каждый раз форкать?)

Помню, не единожды был гемор через то, что в библиотеке некоторый код в private-методе, а не в protected

через композицию

А технически как реализовать?

Ага, вот последний пример: я использовал компонент Process симфонии, всё было хорошо пока не понадобилось вывод одного процесса направить в другой. Через симфони это работает вместо 10 секунд больше часа... А исправить не возможно, нужный метод где можно исправить проблему private... Финиш... Надо либо форк делать, либо другой компонент искать и много чего переписывать...

Читал где-то рекомендацию использовать private в своих проектах, а в опенсорсных или просто в библиотеках - protected

Как ты относишься к final в коде фреймворка Yii 3?

Хз, не смотрел) Будем на практике шатать

Ну вот мне кажется final как раз и нужен в основном фреймворкам и внешним компанентам, дабы оградить компонент от внешнего (глупого) вмешательства. В своём приложении особого смысла его использовать нет. Но опять же не всегда это нужно. Потом PHP это одно, а yii3 это другое. Что хорошие для yii3, не обязательно должно быть хорошо всем остальным. Тут то все началось именно с PHP, а не с yii.

Убрать final при необходимости просто - убрал и все работает, ничего не сломалось. Поэтому мне нравится принцип "делаем всё финальным по умолчанию, если появятся веские причины его убрать - уберем“.

В коде сторонней библиотеки не просто

Да, там сложнее, но тут нужно рассматривать конкретный кейс: - возможно, действительно нужно убрать final и выпустить новую версию - но чаще нужно доработать библиотеку.

Библиотеки используются кардинально разными проектами, с разными релизными циклами. И некоторые просто не станут ждать новой версии если их релизный цикл это 5 минут.

Да, это минус. Но, для меня, этот минус перекрывается плюсами.

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

Nothing is a panacea, it all depends on the case you want to solve, there is never a single solution :)

But rewrite all AssetPublisher becouse of $published is private - i think it's bad idea for me )

Basically the user only sees its advantages, but does not see the maintenance that any package carries.

Да, серебряной пули нет. Но взвешивая плюсы и минусы подхода "final по умолчанию" для меня вывод однозначен — подход правильный.

Ну имхо - часть этих проблем решилась-бы геттерами для приватных свойств, или php 8.1 readonly - о последнем правда пока только мечтать

If there are still people complaining that PHP 5.6 is not supported :)

Новые пакеты, скорей всего, будут уже идти с минимальной версией 8.1. И уже зарелизенные скоро подтянутся.

5.3 with register_globals = On; :)

Было бы неплохо - геттеров зачастую очень нехватает

Ларавел и симфони повлияли? Когда писал про 8 версию, в никакую не хотели поднимать минимальную версию.

Многие из зарелизенных пакетов уже используются в текущих проектах, которые ещё не переехали на 8.1.

There are already some Yii3 packages in 8.0 and 8.1

это и было аргументом, почему не хотели поднимать версию, но можно же было в новой версии поднять требования, а проекты зафиксировать версию пакета пока не перейдут на последний php. Не хотели поднимать требования даже на пакетах которые не были зарелизены.

время идёт, ситуация меняется

Ну а что в этом такого? Когда 3 версия начиналась, было последняя версия 7.4. сейчас она не поддерживается и много людей уже переехали на 8 и 8.1. В свою очередь мы тоже обновляем минимальные требования. Через год-второй глядишь и 8.1 не будет поддерживаться и это совершенно нормально.

Когда я предлагал поднять требования фреймворка до последней недавно релизнутой 8 php, до релиза самого фреймворка было еще далеко. Релиз фреймворка примерно ожидался к срокам приближения к RC 8.1, поэтому не видел никаких причин писать фреймворк под 7.4. В новых релизах фреймворка тратить время на изменения под новые версии php, которого у core разработчиков и так нет, и плюс оглядываться на приложения, которые уже зависят от фреймворка. Учитывая почти маниакальную зависимость на обратной совместимости у всех фреймворков, из-за которого не могут вносить изменения в свои пакеты ломающие обратную совместимость, когда могли сразу писать под последнюю версию php не имея таких проблем до релизов. Ссылаются на то что мало еще людей используют последнюю версию php, поэтому не видят смысла пока писать под нее. Как приложения должны попробовать новую версию, если фреймворки от которых они зависят не имеют ее поддержки? Сейчас же получается, что приложения и фреймворк пинают мяч друг другу, сначала вы начните использовать последнюю версию, а потом и мы подтянемся. Как по мне фреймворк должен двигать сообщество к развитию и использовать лучшие практики на данный момент в программировании. "Через год-второй глядишь и 8.1 не будет поддерживаться и это совершенно нормально." Зачем быть в роли догоняющих, отставать на 1-2 года, что в it может быть критично, если можно предлагать современные "прогрессивные" решения. А то получается все сидят на старых версиях, еле шевелятся с переходом на новые версии php, из-за чего rfc для изменений самого php с выбросом легаси и других изменений не могут пройти голосование, поэтому программисты уже предпочитают перейти на go или другой язык, пока в php, что-то с места сдвинется.