-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[5.0] Add return types in final classes #31996
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
Conversation
9d057c9
to
eff1a66
Compare
@@ -62,10 +62,7 @@ public function attach(string $file, string $name = null, string $contentType = | |||
} | |||
} | |||
|
|||
/** | |||
* @return $this |
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.
Acutally, this is not the same.
- $this means it's exactly the same object
- self means it's may be another instance of this class
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.
yes please add the return type but keep the phpdoc in this case
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.
We need to settle on a policy here.
Personally, I feel link using self is more wrong than correct, so using object
+ the annotation might be more accurate / less misleading.
But that's just my opinion :)
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.
: self
is as close as we can get to @return $this
at the moment. However, as long as php does not support covariant return types, using : self
here might create awkward situations when overriding such a method or when moving it to a superclass.
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 typhinting object
for $this
is bad. For IDEs that don't support $this, having an object return type means nothing. It does not provide typesafety as would self
do in most cases. So for users, self is much better.
The argument was it can provide awkward situation when overriding. But this PR is about final classes which should not be overridden. So again would only affect us maintainers and PHP would complain about it directly in PHP <7.4. So not a problem.
So I'm in favor of using self
which is the closest to $this
.
yes please if possible
yes, when possible too (i.e. only one type is returned)
I don't think void provides much benefit so I would suggest to not added, that will save us from some merge conflicts.
At least not in this PR to me, see my comment on it.
sure |
...ony/Component/Form/Extension/Core/DataTransformer/DateTimeImmutableToDateTimeTransformer.php
Show resolved
Hide resolved
src/Symfony/Component/HttpKernel/EventListener/ExceptionListener.php
Outdated
Show resolved
Hide resolved
d6204e8
to
e2b9039
Compare
e2b9039
to
8654241
Compare
28697c9
to
9ba130b
Compare
9ba130b
to
7eb5ca3
Compare
7eb5ca3
to
f84d094
Compare
f84d094
to
85e568d
Compare
85e568d
to
ca5ae19
Compare
Thank you @dFayet for fixing reviews comments so fast |
This PR was merged into the 5.0-dev branch. Discussion ---------- [5.0] Add return types in final classes | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes/no <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no | Deprecations? | no | Tests pass? | no | Fixed tickets | #31981 | License | MIT | Doc PR | symfony/symfony-docs#... <!-- required for new features --> This is the first step for the issue #31981 I have some questions: - ~I have not added type for methods with `@inheritdoc` annotation, should I?~ - ~Don't we want to type also functions without `@return` annotation? (still in `final` classes)~ - ~If yes is the answer of the previous one, do we also want the `void` return type?~ - ~I have also added the return type in the `DependencyInjection` PhpDumper, but is it also wanted? (if yes, I will clean a bit the code changed)~ - ~Should we update the documentation's code samples when they display `final` classes?~ Todo: - [x] Adjust the PR, following the answers of the questions - [x] Add return type also when there is no `@return`, or with `@inheritdoc` - [x] [src/Symfony/Component/Debug/ErrorHandler.php#L383](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Debug/ErrorHandler.php#L383) `@return` annotation is not correct according to the return, investigate and adjust if needed - [x] [src/Symfony/Component/HttpKernel/ControllerMetadata/ArgumentMetadataFactory.php#L50](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/ControllerMetadata/ArgumentMetadataFactory.php#L50) `@return` annotation is not correct according to the return, investigate and adjust if needed - [x] Do a PR on documentation to add return type on code snippets with final classes => unneeded as they were already typed Commits ------- ca5ae19 Replace @return annotation by return type in final classes
This PR was merged into the 5.0-dev branch. Discussion ---------- add missing return type in User class | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | #... <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | symfony/symfony-docs#... <!-- required for new features --> Fixed a missing type in #31996 chasing #17201 Every method in this class had a return type but this method. Commits ------- 7857f2f add missing return type in User class
…lver (Tobion) This PR was merged into the 4.4 branch. Discussion ---------- use proper return types in ErrorHandler and ArgumentResolver | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | tiny | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | | License | MIT | Doc PR | Found those things while reviewing #31996 which missed some return types due to using `return` instead of `return null`. It's part of fixing #17201 (due to #10717). See also #30869 that somebody was stumbling over. Commits ------- 2f9121b use proper return types in ErrorHandler and ArgumentResolver
This PR was merged into the 5.0-dev branch. Discussion ---------- [Lock] Fix return typehint | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | NA | License | MIT | Doc PR | NA Return typehint added in #31996 ping @dFayet Commits ------- e28ffe8 Fix return typehint in Lock
This PR was merged into the 5.0-dev branch. Discussion ---------- [5.0] Add return types in final classes | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes/no <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no | Deprecations? | no | Tests pass? | no | Fixed tickets | symfony#31981 | License | MIT | Doc PR | symfony/symfony-docs#... <!-- required for new features --> This is the first step for the issue symfony#31981 I have some questions: - ~I have not added type for methods with `@inheritdoc` annotation, should I?~ - ~Don't we want to type also functions without `@return` annotation? (still in `final` classes)~ - ~If yes is the answer of the previous one, do we also want the `void` return type?~ - ~I have also added the return type in the `DependencyInjection` PhpDumper, but is it also wanted? (if yes, I will clean a bit the code changed)~ - ~Should we update the documentation's code samples when they display `final` classes?~ Todo: - [x] Adjust the PR, following the answers of the questions - [x] Add return type also when there is no `@return`, or with `@inheritdoc` - [x] [src/Symfony/Component/Debug/ErrorHandler.php#L383](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Debug/ErrorHandler.php#L383) `@return` annotation is not correct according to the return, investigate and adjust if needed - [x] [src/Symfony/Component/HttpKernel/ControllerMetadata/ArgumentMetadataFactory.php#L50](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/ControllerMetadata/ArgumentMetadataFactory.php#L50) `@return` annotation is not correct according to the return, investigate and adjust if needed - [x] Do a PR on documentation to add return type on code snippets with final classes => unneeded as they were already typed Commits ------- ca5ae19 Replace @return annotation by return type in final classes
This is the first step for the issue #31981
I have some questions:
I have not added type for methods with@inheritdoc
annotation, should I?Don't we want to type also functions without@return
annotation? (still infinal
classes)If yes is the answer of the previous one, do we also want thevoid
return type?I have also added the return type in theDependencyInjection
PhpDumper, but is it also wanted? (if yes, I will clean a bit the code changed)Should we update the documentation's code samples when they displayfinal
classes?Todo:
@return
, or with@inheritdoc
@return
annotation is not correct according to the return, investigate and adjust if needed@return
annotation is not correct according to the return, investigate and adjust if needed