Hi Alexandru, to be completely truthful, your case shouldn't be an issue for us, because we're starting from the assumpion that that implementation follows the PSR, which also describe (at the very least with PHPDoc) what types are allowed. If the implementation allows other types (on top of the requested ones), it's not our concern, per Liskov Substitution principle.
The major is requested to the end users only when adding the argument types which, since it's narrowing it's accepted types, is a BC due to the same principle. Il giorno lunedì 7 ottobre 2019 13:22:26 UTC+2, Alexandru Pătrănescu ha scritto: > > Hi George, Alessandro, > > I had this idea that this could be a minor version as well: > https://twitter.com/drealecs/status/1180258126215430150 but few minutes > later realized that it's not going to work everywhere without BC break on > the client side. > > If an interface was designed to accept a specific parameter type TypeA > but, being defined without a parameter type declaration, the implementation > could maybe allowed it to accept other types there: TypeB. > A client would be able in the current version to call the interface with > parameter TypeB. > After tagging a new minor version with parameter TypeA, client code will > break. > > To be perfectly safe, we need to mark it as a major version and all > libraries are required to make a small change. > > Regards, > Alex > > On Mon, Oct 7, 2019 at 11:10 AM Alessandro Lai <[email protected]> > wrote: > >> Hello George, >> I agree with you with the first part: the first step in our proposal >> could be easily wrapped in a minor release, it shouldn't hinder the >> adoption, and it would even encourage it, since it would be automatically >> adopted by any package that declares ^1.0 as a constraint. >> But making the second step (with return types) is IMHO the good step >> forward then, because it would push the standard forward, accompanying any >> library that would add return types, maybe thanks to PHP 7.4 too. >> >> Il giorno sabato 5 ottobre 2019 15:21:47 UTC+2, G. P. B. ha scritto: >>> >>> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/40acb6f0-2ac8-472d-aa33-d9048e026c70%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/40acb6f0-2ac8-472d-aa33-d9048e026c70%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/e91b3c88-c434-4a3d-bbf4-194b3340f369%40googlegroups.com.
