-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Console] Add return type to OutputFormatterInterface::format() #42382
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Add return type to OutputFormatterInterface::format()
Signed-off-by: Alexander M. Turek <me@derrabus.de>
- Loading branch information
commit d75f5e62df880b7f0b68e0b27f7f9de76a0a3dbe
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this must be
@return string
and the null formatter should bereturn $message;
instead.symfony/src/Symfony/Component/Console/Output/Output.php
Line 157 in 49a076a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep in mind that this is not an internal class. You are suggesting to significantly change its behavior here while I'm merely documenting the status quo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, indeed. I'm not sure what is the best way forward.
If we officially document this contract as returning
string|null
, we have to update all code using this function to take care of thenull
return. Honestly, returning null (void actually) inNullOutputFormatter
seems like a mistake and bug to me.In fact, if code is build to use the normal
OutputFormatter
, it would be broken ifNullOutputFormatter
is used in the test. I can't think of any reasonable approach to build code to only work withNullOutputFormatter
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand. But
string|null
is what currently is returned from the implementations. Once this PR is merged, we can think about how we could narrow it down to juststring
in 6.0. By the way, I'd also like to do this for the$message
parameter.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we depreciate null in 5.4 then? Then we can keep the implied contract, which is string IMHO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the real issue is the implementation of
NullOutputFormatter
which was written before void was introduced. Conceptually, doing nothing was the same as returningnull
back then. Let's merge this one as is and see if we can deprecatenull
in a followup PR (same for*message
).