Hey FIG, It's been a while since I last posted here. Just wanted to give a huge +1 to Stefano Torresi proposal. Having a different package with a different namespace for major version would solve compatibility issues instantly. I think this is something we ought to consider.
Also, this is something that has already be done in other languages. For instance, when Microsoft releases a new version of DirectX, it prefixes all classes with the version: https://docs.microsoft.com/en-us/windows/win32/api/d3d11/ Without going as far as Stefano proposes, it could possible to propose a v2 without completely changing the naming scheme. For instance v2 of PSR-11 could be: - Namespace: Psr\Container\v2 - package: psr/container2 Stefano's idea is far from crazy, it totally makes sense. Additionally, you can mark "psr/container" as deprecated in composer, asking to migrate to "psr/container2" in order to speed up adoption. ++ David. Le samedi 5 octobre 2019 15:21:47 UTC+2, G. P. B. a écrit : > > Greetings PHP-FIG, > > > From my understanding this project is to add parameter and return types to > some of the interfaces defined in PSRs before those exists in PHP. > > > First, adding parameter types is the easiest and also, in my mind, the > most important type information to add, as it is impossible to add a more > specific type from a mixed type as it goes against LSP. > This is easy to add as it doesn't break compatibility with current > implementations, as parameter types can be widened. > Adding parameter types can be tagged as a version 1.1.0 because semver > allows to upgrade dependencies in minor version. i.e. updating the PHP > version is a dependency update. > > Determining whether the change is a patch level or minor level >> modification depends on whether you updated your dependencies in order to >> fix a bug or introduce new functionality. I would usually expect additional >> code for the latter instance, in which case it’s obviously a minor level >> increment. > > > See FAQ on https://semver.org/ > > Secondly adding return types, this cannot be done in a BC compatible way > as having a wider (i.e contravarient) return type breaks LSP. > However, I would argue that with the imminent release of PHP 7.4 this is a > non-issue. > Indeed PHP 7.4 comes with the feature of contravarient parameter types > (i.e type widening) and covarient return types (i.e limiting the return > type). > This means that a library will be able to add return types even though the > PSR interface doesn't specify a return type if it decides to only support > PHP 7.4 as a minimum version, which IMHO is bound to happen as there are a > ton of features bundled with this release of PHP. > > I hope that everyone can agree that adding parameter types in a minor > version of the PSR spec and leaving return types alone is a better plan > than, IMHO, the various other proposals which seem unnecessary complicated. > > Best regards > > George Peter Banyard > > > > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/e7154f93-10cb-44c7-a885-7c31fb1a4e7c%40googlegroups.com.
