Namespaced interfaces won't work because there's no method overloading in PHP thus a library can not implement two versions of the interface at the same time.
чт, 19 сент. 2019 г., 8:35 Alexandru Pătrănescu <[email protected]>: > I apologize if my answer didn't provide clearer cases where this solution > that seems to be the simplest one is just not working: > > - If I have a small project where I use slim framework and guzzle http > client, both having implementation of PSR-7, I should be allowed to upgrade > each one to another major version with no impact on the other. > If the project is bigger, you might find more than two implementations, > including PSR-17 factories that also implements PSR-7. > > - Another example would be the case of PSR-11, the container > interoperability interface and actually all interop related PSR that by > design are meant to allow projects with more than one implementation at > runtime. > > There are problems that could require a more complex solution, but still > the simplest that would work. > I believe namespaced interfaces would be needed here. > > Alex > > > On Thu, Sep 19, 2019 at 7:40 AM Adrien Crivelli <[email protected]> > wrote: > >> >> On Wednesday, 18 September 2019 17:17:29 UTC-7, Edward Almasy wrote: >>> >>> On Sep 18, 2019, at 2:07pm, Cees-Jan Kiewiet <[email protected]> wrote: >>> >>> From a consumers perspective the namespaced revisions sounds like hell >>> to me to be honest. As a consumer I care about the highlevel >>> Psr\Log\LoggerInterface interface, not whether it's rev1, 2, or 35. To me >>> the packages for each PSR should be handled like any other PHP package and >>> receive major new versions introduction updates/maintenance for that >>> package. And as a consequence only one version of a PSR should be active, >>> like PSR-12 supersedes PSR-2 or PSR-4 supersedes PSR-0. This means that >>> consumers should always be moving forward, but at their own pace. >>> >>> >>> I'd like to second this sentiment. Simplicity promotes clarity and >>> adoption >>> >> >> Me too, find that using the de-facto standard of managing dependencies >> and their breaking version is the simplest and best way to approach this. >> >> If your lib inherit from a PSR interface, then you cannot support both >> PSR major versions at once, but you can, and should, release a new major of >> your lib with the support of latest PSR version. This is how it is done for >> pretty much everything else since composer came to be. I don't see why it >> could not be applied to PSR too. >> >> Please, Keep It Stupid Simple. >> >> >> -- >> 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/0e8c8755-e554-429b-bf45-639d57d97574%40googlegroups.com >> <https://groups.google.com/d/msgid/php-fig/0e8c8755-e554-429b-bf45-639d57d97574%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/CAAwdEzDCm7Dj3ucj1CKE9OkgQdQ8p-Y-9sT_41dSUr0niBDJ%3DA%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAAwdEzDCm7Dj3ucj1CKE9OkgQdQ8p-Y-9sT_41dSUr0niBDJ%3DA%40mail.gmail.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/CA%2BFA5VU1j4CbksDCpocpe%3DeqKRU-Yep4fVBuRyWPOdqkeYoZ7A%40mail.gmail.com.
