laminas
Deprecate Http Message and Mvc Interfaces/Classes
| Q | A |
|---|---|
| Documentation | no |
| Bugfix | no |
| BC Break | no |
| New Feature | no |
| RFC | no |
| QA | no |
Description
In light of laminas-mvc being retired and its related packages set as security only -
This PR deprecates the Interfaces and classes that laminas-mvc depends on that has been replaced by laminas-diactoros and its PSR7 implementation.
Additional deprecations outside of the strictly PSR7 related interfaces/class:
- ParametersInterface
- Parameters
- DispatchableInterface
Does anyone else have opinions on deprecating the Laminas\Http / MVC related interfaces and base classess here? Paging @laminas/technical-steering-committee for additional review
I feel that there is too much focus on MVC, even though this is only a standard library. Sure, it is used by MVC, but it gives the impression that the dependency is the other way around. The real reason is that PSR-7 should be used instead of the interfaces that exist here.
Well, I'm happy to make whatever changes are required once a consensus can be reached or close it.
Please remember that laminas-http also uses the interfaces and the Message class, is not an MVC component either, and is still required in many other Laminas packages:
- laminas-feed
- ~laminas-router~
- laminas-soap
- laminas-recaptcha
- laminas-authentication
- laminas-test
- laminas-navigation
- laminas-xmlrpc
We should just be aware that it could generate many more questions and work.
In an ideal world I would say all of those packages should depend on PSR-7.
In an ideal world I would say all of those packages should depend on PSR-7.
This is correct but unfortunately, this means a lot of work, and until everything has been changed over, there will be many questions. I just want to point that out.
Well, I'm not trying to create a bunch of "extra" work. Constantly having to explain what is happening can be "a lot of work" as well.
So in light of the need for some discussion/planning etc should I set this as a draft and come back to it once a path has been charted and work completed to a point where it's beneficial to make these changes without causing the additional work?
My intent with this PR was mainly to prevent code that should be deprecated in the near future from being overlooked similar to the code that should have been removed in laminas-hydrator V4. I fully understand how short handed the project is and completely understand how limited dev hours are.
@tyrsson Your intention is correct because it is a clear signal that these interfaces and classes are coming to an end and changes need to be made. On the other hand, there are active packages such as laminas-http, which is used in laminas-router, and this router has an implementation in Mezzio. Therefore, I am setting your PR to draft.