Clarification on the purpose of this extension. about php-psr

[JoyceBabu]

Thank you for the clarification.

[sergeyklay]

Does that mean that the extension is only for use with other extensions that depend on this?

Primarily yes. But you can easily use it for any project from PHP land as dependency provider. At least to not install the same dependencies for each of project on the same workstation/server.

Is there any advantage in standalone use of this extension instead of the standard composer package offered by PHP-FIG?

As long as this project is fully compliant with the specifications, it makes not so much sense to satisfy these specifications using PHP. Yes, you still can, but it is not clear what problem do you solve by simply copying (from packagist.org) PHP-based interfaces each time to a new project. Can you elaborate on that? On the other hand, there are some extensions (like iterators, exceptions, SPL and so on), it seems nobody not plans to port to PHP :) Actually, the more interested question for me is why this project is not part of the PHP yet?

[JoyceBabu]

Thank you. Having to install only once is an advantage in theory, but I am not sure how effective that would be in practice.

For example, if you are using a composer package that require psr/http-message-implementation, then the package that provides it will most probably depend on psr/http-message. Hence it would be installed anyway.

[sergeyklay]

For example, if you are using a composer package that require psr/http-message-implementation, then the package that provides it will most probably depend on psr/http-message. Hence it would be installed anyway.

From this side it may seem convenient. However, AFAIK, it is not a best practice to depend for a dependency which is a dependency of another dependency. If you're agree on that, then you'll always install all the dependencies explicitly (and specify desired versions) and do not relly that library A most probably depend on B.

[jbboehr]

@sergeyklay is correct, but I'll just chime in with my own thinking:

If you want to develop or consume an extension that uses the PSR interfaces, the interfaces need to be provided at the extension level. As an extension developer, you could embed them in your own extension, but that could potentially lead to conflicts if more extensions do the same. So I and others developed this extension so they can be shared between any number of extensions (and normal PHP code, of course).

As for regular PHP code, there isn't a whole lot of use outside of questions of taste or minor optimization. For example: you could also use the extension to save having to load the PSR .php files. This may make a minor efficiency improvement to cold starts or CLI. Or maybe you just prefer extensions because once the extension is loaded, they'll never fail to autoload any of the classes. Or maybe you prefer to manage your dependencies using the system package manager instead of composer.