Skip to content

[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

Merged
merged 1 commit into from
Jun 23, 2019

Conversation

dFayet
Copy link

@dFayet dFayet commented Jun 11, 2019

Q A
Branch? master
Bug fix? no
New feature? yes/no
BC breaks? no
Deprecations? no
Tests pass? no
Fixed tickets #31981
License MIT
Doc PR symfony/symfony-docs#...

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:

@dFayet dFayet requested review from dunglas, lyrixx and sroze as code owners June 11, 2019 14:16
@dFayet dFayet force-pushed the feature/strict_type_final branch 2 times, most recently from 9d057c9 to eff1a66 Compare June 11, 2019 14:24
@@ -62,10 +62,7 @@ public function attach(string $file, string $name = null, string $contentType =
}
}

/**
* @return $this
Copy link
Member

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

Copy link
Contributor

@Tobion Tobion Jun 11, 2019

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

Copy link
Member

@nicolas-grekas nicolas-grekas Jun 11, 2019

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 :)

Copy link
Member

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.

Copy link
Contributor

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.

@nicolas-grekas nicolas-grekas added this to the 5.0 milestone Jun 11, 2019
@nicolas-grekas
Copy link
Member

I have not added type for methods with @inheritdoc annotation, should I?

yes please if possible

Don't we want to type also functions without @return annotation? (still in final classes)

yes, when possible too (i.e. only one type is returned)

If yes is the answer of the previous one, do we also want the void return type?

I don't think void provides much benefit so I would suggest to not added, that will save us from some merge conflicts.

I have also added the return type in the DependencyInjection PhpDumper, but is it also wanted?

At least not in this PR to me, see my comment on it.

Should we update the documentation's code samples when they display final classes?

sure

@dFayet dFayet force-pushed the feature/strict_type_final branch 3 times, most recently from d6204e8 to e2b9039 Compare June 12, 2019 07:21
@dFayet dFayet force-pushed the feature/strict_type_final branch from e2b9039 to 8654241 Compare June 15, 2019 06:42
@dFayet dFayet changed the title [WIP][5.0] Replace @return annotation by return type in final classes [5.0] Add return types in final classes Jun 15, 2019
@dFayet dFayet force-pushed the feature/strict_type_final branch 2 times, most recently from 28697c9 to 9ba130b Compare June 16, 2019 09:42
@dFayet dFayet force-pushed the feature/strict_type_final branch from 9ba130b to 7eb5ca3 Compare June 16, 2019 10:29
@dFayet dFayet force-pushed the feature/strict_type_final branch from 7eb5ca3 to f84d094 Compare June 20, 2019 14:43
@dFayet dFayet force-pushed the feature/strict_type_final branch from f84d094 to 85e568d Compare June 21, 2019 07:50
@dFayet dFayet force-pushed the feature/strict_type_final branch from 85e568d to ca5ae19 Compare June 22, 2019 22:57
@Tobion
Copy link
Contributor

Tobion commented Jun 23, 2019

Thank you @dFayet for fixing reviews comments so fast

@Tobion Tobion merged commit ca5ae19 into symfony:master Jun 23, 2019
Tobion added a commit that referenced this pull request Jun 23, 2019
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
chalasr pushed a commit that referenced this pull request Jun 25, 2019
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
@dFayet dFayet deleted the feature/strict_type_final branch June 25, 2019 08:58
fabpot added a commit that referenced this pull request Jun 26, 2019
…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
nicolas-grekas added a commit that referenced this pull request Aug 8, 2019
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
@fabpot fabpot mentioned this pull request Nov 12, 2019
hultberg pushed a commit to hultberg/symfony that referenced this pull request Sep 17, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants