Зачем?

Если вам нужен PSR-кеш, ну требуйте его в конструктор.

В комплексном чтении истории сообщений ;)

$object->method($yiiCache)  - метод принимает PSR interface

раньше было ок, теперь будет не ок, придётся два кеша таскать за собой.

Ну и норм. Ничего ужасного.

Нужен PSR, хинть на PSR.

Нечего неявно завязываться на то, что не нужно.

А если уже завязано давно?

Сейчас это выглядит так, что никому не интересен этот пакет. Скорее возьмут аналогичный с такими методами в интерфейсе вместе с psr

Как настроить проверку покрытия тестами?
phpunit выдаёт ошибку
Warning:       XDEBUG_MODE=coverage or xdebug.mode=coverage has to be set

php8, xdebug3, win10

Установи этот флаг, в 3 дебаге иное конфигурирование

где?

Ну или php -dxdebug.mode=coverage {command}

Ну, переписать.

Там правок совсем чуть.

Php.ini :)

спасибо)))

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

1) Я не хочу думать какой там парент у того кеша, а хочу просто передать куда то PSR16 совместимую его версию.
2) Я к примеру использую несколько кешей (файловый для больших данных, MemCached для каких то других и APCu для малых критически важных данных). Кеши конфигурируются где то там. На деве они могут ссылаться все на файловый кеш или на заглушку. Конечные компоненты получают на вход yii кеш и не знают что им там и с каким парентом передали. Как в компоненте получит PSR совместимый кеш? Прокидывать его по всей цепочке? (по тому что вы считаете что нефиг пользователю иметь доступ к паренту 😀).

3) Я бы слово parent заменил на более понятное типа psrСache и добавил метод getPsrCache().
4) Использование одного хранилище для значений и тегов... Серёзно?
5) Не хватает ValueDependency ( вместо new CallbackDependency(fn () => $value) ).
6) У интерфейса CacheInterface всего 2 метода. Забавно...

Во, и этот умеет по-русски)

1) Да, это сейчас можно. Именно так и работает.