10000 Proposal for the creation of interfaces for the Symfony HttpFoundation component · Issue #50018 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Proposal for the creation of interfaces for the Symfony HttpFoundation component #50018

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
AlessandroAmos opened this issue Apr 14, 2023 · 6 comments
Closed

Proposal for the creation of interfaces for the Symfony HttpFoundation component #50018

AlessandroAmos opened this issue Apr 14, 2023 · 6 comments
Labels
HttpFoundation RFC RFC = Request For Comments (proposals about features that you want to be discussed)

Comments

@AlessandroAmos
Copy link

Description

I believe that to make the code decoupled, it would be interesting to create these interfaces to use, for example, in the httpkernel that forces me to use the http-foundation!

Example

No response
@stof
Copy link
Member
stof commented Apr 14, 2023

Which interface would you like ? HttpKernel depends on Request and Response which are value objects. Creating interfaces for them does not really make sense (not counting the fact that Request exposes public properties, which cannot be described in an interface and so this would not be possible without first changing the API)

@AlessandroAmos
Copy link
Author

My idea is precisely for use in HttpKernel. It would be to create a RequestInterface that would remove the requirement of using the Request class in the execution of the kernel. And why not change the API to retain these values?

@stof
Copy link
Member
stof commented Apr 14, 2023

Changing the API is a BC break (and changing the Request class is a huge one for the ecosystem).

And I don't see the benefit of this RequestInterface: what is the benefit of re-implementing the whole API of the Request each time instead of using the value object provided in Symfony ?
Side note: it would make it a lot harder to add new helper methods in the Request object as adding new methods in an interface is a BC break so it requires adding it though a forward compatibility layer and adding it in the interface only in the next major. So this does not only has a huge migration cost for the ecosystem but also a bigger maintenance cost.

@wouterj
Copy link
Member
wouterj commented Apr 14, 2023 •
edited
Loading

We've discussed the topic of refactoring request/response and adding (or supporting) interfaces multiple times in the past in this issue tracker (e.g. #6406, #15414 and #17392). The conclusion has always been the same as @stof shared in his previous message (note that the BC layer for changing function parameters from an object to interface is also not trivial and probably requires duplicating all methods that have Request as a typehint at the moment).

Unless something is changed since these previous issues that reduces the impact on the ecosystem or maintainers, or there is a real benefit of not using HttpKernel together with HttpFoundation, I'm -1 for this.

@derrabus
Copy link
Member

that would remove the requirement of using the Request class in the execution of the kernel

I fail to see how this solves any problem, tbh. An interface would make backwards-compatible changes to our request and response objects a PITA, as would the migration towards those interfaces. Not worth it imho, sorry.

@derrabus derrabus added HttpFoundation RFC RFC = Request For Comments (proposals about features that you want to be discussed) labels Apr 14, 2023
@nicolas-grekas
Copy link
Member

Closing for the given reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
HttpFoundation RFC RFC = Request For Comments (proposals about features that you want to be discussed)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@nicolas-grekas @stof @wouterj @derrabus @AlessandroAmos
0