Yes, you are right and, of course, there needs to be different classes implementing different incompatible interface versions.
And this would introduce flow control conditions in dependent libraries. It's not a simple solution, as I mentioned. But I think it might be the simplest one if we would want to allow upgrading major version of slim without upgrading to a major version of guzzle. I'll take more time and try to analyse and understand how a real world example would look like. Maybe how guzzle separated the PSR-7 implementation in a different package would help with the same-namespace version. Problem appears with packages implementing the interface and not with packages calling methods of the interface (because of the different coupling level, mentioned earlier). So separating implementations in a different package that could be maintained longer time in different major versions might work. On Thu, Sep 19, 2019 at 9:19 AM 'Alexander Makarow' via PHP Framework Interoperability Group <php-fig@googlegroups.com> wrote: > 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 <dreal...@gmail.com>: > >> 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 < >> adrien.crive...@gmail.com> wrote: >> >>> >>> On Wednesday, 18 September 2019 17:17:29 UTC-7, Edward Almasy wrote: >>>> >>>> On Sep 18, 2019, at 2:07pm, Cees-Jan Kiewiet <cees...@gmail.com> 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 php-fig+unsubscr...@googlegroups.com. >>> 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 php-fig+unsubscr...@googlegroups.com. >> 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 php-fig+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CA%2BFA5VU1j4CbksDCpocpe%3DeqKRU-Yep4fVBuRyWPOdqkeYoZ7A%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CA%2BFA5VU1j4CbksDCpocpe%3DeqKRU-Yep4fVBuRyWPOdqkeYoZ7A%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 php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAwdEzD1m3G%2B3h%3DGK4qMfbGXbh%3DWokhdk9NLF%2BjQnDj5RdJ9SQ%40mail.gmail.com.
