Deprecate Http Message and Mvc Interfaces/Classes

[tyrsson]

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

[gsteel]

Thanks @tyrsson - Just a few nitpicks from me 👍

[gsteel]

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

[arhimede]

I think it can be removed//deprecated everything related to MVC

[froschdesign]

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.

[tyrsson]

Well, I'm happy to make whatever changes are required once a consensus can be reached or close it.

[froschdesign]

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.

[tyrsson]

In an ideal world I would say all of those packages should depend on PSR-7.

[froschdesign]

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.

[tyrsson]

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.

[froschdesign]

@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.

[tyrsson]

I could have sworn I had done that. Anyway, agree 100%. Thanks.

[froschdesign]

laminas-router uses this interface:

namespace Laminas\Router;

use Laminas\Stdlib\RequestInterface as Request;

interface RouteInterface
{
    /**
     * Match a given request.
     *
     * @return RouteMatch|null
     */
    public function match(Request $request);

    // …

https://github.com/laminas/laminas-router/blob/ec4b33834199bcf04c1b90b98c10f53c9e77e046/src/RouteInterface.php#L29-L34

And laminas-router is one of the router implementation of Mezzio.