так ругается когда в scrutinizer на заведена репка

Понял, спасибо.
Если всё ок - можно ревьювить. С пхп 8 там пока видимо с токенами проблема.

Как-то уже поднимался вопрос про финальные классы в фреймворке. Решили что-нибудь? Столкнулся с проблемой, что коннекшен к постгресу финальный - а мне надо было для него декоратор сделать. Получается, что меня фреймворк ограничивает в расширении, и я тупо не могу им пользоваться. Имхо надо final выпиливать, а то на большом кол-ве классов он уже висит.

Чтобы сделать декоратор - не надо наследоваться же…

Надо, что бы можно было его передавать вместо родителя.

Тут нужна зависимость от интерфейса

Поднимался и решался. Решили так: если класс финальный и в нем что-то не настраивается - это баг. Если нужна другая реализация и нет интерфейса - тоже баг.

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

В этом случае это уже не декоратор, а другая реализация интерфейса.

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

Да, так тоже ок в идеальном случае, но вот Yiisoft\Db\Connection не имеет интерфейса для > 80% публичных методов. И создав декоратор от ConnectionInterface там будет только 7 методов. Но тут уже больше вопрос не к финалу, а к интерфейсам фреймворка.

Думаю имеет смысл создать issue с твоим кейсом. «если класс финальный и в нем что-то не настраивается - это баг.»

Или сразу PR с расширением интерфейса.

А можно пример? Похоже вы хотите что то сделать не правильно...

Я уже поковырял коннекшен, похоже он мне тоже не сильно поможет, даже без final - слишком много переопределять придется. Проблема не совсем типовая: приложение не умирающее, живет в памяти с помощью RoadRunner. И ждет на сокете подключения клиента. Таких воркеров 1000. В один момент, с базой что-нибудь случилось, или с сетью - не важно, коннешен к ней умер и сразу поднялся. И во всех 1000 инстансах приложения, в уже существующих $connection->pdo связь оборвана, но это никак не возможно ни проверить, ни обработать на уровне класса Connection. isActive проверяет только инстанцирования PDO - оно есть, а подлючение в нем уже нет. Думал сделать какую-нить обертку и в ней в случае падения запроса пробовать пересоздавать подключение, и если не удалось - то уже эксепшен. Но похоже придется все это обрабатывать на уровне репозитория (( Но даже тут проблема в том, что  методы open и close в ConnectionInterface не поисаны, сейчас на это PR сделаю. Если есть идеи как такую ситуацию можно обработать - будет интересно выслучашть.

Хм... а может доработать isActive чтобы проверял ещё и состояние PDO?

Или это невозможно узнать без пинга?

Пока какой-нить sql запрос не выполнить, это никак не узнать даже через PDO.

В моей голове решение выглядит как некий сервис с методом actualizeConnection, который выполняет простой запрос, и в случае падения из-за отсутствия соединения пытается восстановить его.