search

jbboehr / php-psr

PHP extension providing the accepted PSR interfaces
Other
231 stars 32 forks source link

Compatibility with newer psr libraries #87

Open jbboehr opened 3 years ago

jbboehr commented 3 years ago

Currently there is a 2.0 out of psr/container and psr/link which require PHP 8.0 and are not compatible with the libraries we test against. We should review other PSR repos for newer versions develop an upgrade plan.

See #84

jbboehr commented 3 years ago
jbboehr commented 3 years ago

Proposal: branch master off to 1.x, new master (2.x) requires PHP 8.0 and supports the newer psr interfaces.

erickcomp commented 3 years ago

The PSR-11 version 2.0.0 added the bool return type to the has method of the ContainerInterface;

https://github.com/php-fig/container/releases/tag/2.0.0

Does this have any incompatibilities with current implementation? I think a change could be made to the container interface so it matches the psr 2.0.0 and make it available for PHP 7

Thanks for your work!

jbboehr commented 3 years ago

@erickcomp Yeah, it's super not backwards compatible for implementing libraries. I would have to have a 2.0 for PHP7 and a 3.0 for the other PSRs, was hoping to minimize the number of major versions of the repo. Especially since there isn't a good way of managing versions of the extension like you can libraries with composer.

jbboehr commented 3 years ago

Change in plans: I will investigate shipping all major versions of each PSR simultaneously, selectable via an INI setting.

For example we will define PsrExt\Cache\v1\CacheInterface, PsrExt\Cache\v2\CacheInterface, PsrExt\Cache\v3\CacheInterface. A system INI setting psr.cache_version will decide which interface is aliased to Psr\Cache\CacheInterface. Perhaps we can have options "" (off) v1 v2 v3 or maybe I'll just make it an integer [0, 3].

In v2.0 the default will still be v1 of each of the PSRs. The class entries exported in the headers as they are now will remain and will point to the aliased class. We will also export class entries for each version in their own headers.

Thoughts and feedback appreciated!

erickcomp commented 3 years ago

Change in plans: I will investigate shipping all major versions of each PSR simultaneously, selectable via an INI setting.

For example we will define PsrExt\Cache\v1\CacheInterface, PsrExt\Cache\v2\CacheInterface, PsrExt\Cache\v3\CacheInterface. A system INI setting psr.cache_version will decide which interface is aliased to Psr\Cache\CacheInterface. Perhaps we can have options "" (off) v1 v2 v3 or maybe I'll just make it an integer [0, 3].

In v2.0 the default will still be v1 of each of the PSRs. The class entries exported in the headers as they are now will remain and will point to the aliased class. We will also export class entries for each version in their own headers.

Thoughts and feedback appreciated!

Awesome! Good for fine tuning between projects. One thing that bugs me out is the fact that the PSR's are inconsistent among themselves. Some of them put type hints on PHPDoc, some put them in the code. They should update the PSR's to make things more consistent about coding standards.

Thank you for your efforts!

jbboehr commented 3 years ago

One thing that bugs me out is the fact that the PSR's are inconsistent among themselves. Some of them put type hints on PHPDoc, some put them in the code.

I wasn't and am not involved in PHP-FIG, but this is most likely due to them targeting the oldest current supported version of PHP when they were authored. And they are updating them, some of them at least, which is what's causing me quite some trouble :)

SvenRtbg commented 2 years ago

In general, providing the PSR interfaces version zoo via an extension is impossible in a consistent way. Composer probably isn't aware that this extension is installed, so the extension will provide a different version of the interface than the software expects and is installing. Combining all PSR interfaces into one extension multiplies the problems because you have to provide all versions combined will all versions. Selecting the versions via PHP INI settings isn't really helping in case one single PHP configuration is expected to power multiple applications that require different interface versions.

And there are practical problems with class_alias() apparantly, that trigger unexpected errors like this: https://github.com/laminas/laminas-servicemanager/issues/124#issuecomment-1091458297