Skip to content
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.

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

ComposesRequestContent->toString() and immutable request content #76

Open
wants to merge 9 commits into
base: 4.x-dev
Choose a base branch
from

Conversation

sanderdlm
Copy link

@sanderdlm sanderdlm commented Mar 27, 2023

Branch started from #74.

2 API improvements with a BC break:

  • AbstractRequest->setContent is removed, making the content of a request immutable. Content can only be defined when creating the request, through the constructor. The script filename was already like this, and having both of them immutable results in a more resilient request object.
  • ComposesRequestContent->getContent renamed to toString, see:
    • The old method name was confusing in the context of a request already having content, which ended up looking like: $request->getContent()->getContent(); toString better illustrates what this method does, which is return a string representation of the request content.

Sander De la Marche added 7 commits March 27, 2023 17:19
Passing a string to any Request is deprecated in 4.x
The old method name was confusing in the context of a request
already have content, which ended up looking like:
$request->getContent()->getContent();

toString better illustrates what this method does, which is return
a string representation of the request content.
This commit removes the setContent setter from the AbstractRequest class.
The only way to set the content of a request is now through the constructor.
Once the content for a request is defined, it cannot be changed.
If new content has to be sent, a new request should be made.
@sanderdlm
Copy link
Author

It doesn't really make sense to me to have a setter for contentType either now. With setContent gone and the content property requiring an implementation of the interface, if someone wants to send a specific type of content, he'll have to create his own class implementing ComposesRequestContent anyway, and by doing so he'll set the content-type in there.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant