Task #101698
open
Remove "final" keyword
0%
Description
More and more classes are marked as "final" in TYPO3.
This should not be done unless in very specific circumstances:
- For security reasons, e.g. when a class name can be selected from an exposed option like a form field, and only when such implementations share an interface and the entire application programs against the interface, not the implementation.
- And that's basically it.
And it should never be done on a class that does not have an interface and where the rest of the framework programs against the specific implementation instead of the interface.
Using "final" as a way to signal that "you shouldn't replace this class" is an abuse of the language construct. Signals should be sent with interfaces or annotations - not by enforcing it as an unavoidable choice imposed on every developer.
The classes that currently declare "final" as well as those that are scheduled to become "final" simply do not fulfill this.
Additionally, "final" without a programmed-to interface is poison for testability in that it prevents the (efficient) creation of test doubles.
Therefore, the "final" keyword should be removed and avoided in the future.
Updated by Gerrit Code Review 9 months ago
- Status changed from New to Under Review
Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 9 months ago
Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 9 months ago
Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 9 months ago
Patch set 4 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 9 months ago
Patch set 5 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 7 months ago
Patch set 6 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 7 months ago
Patch set 7 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 7 months ago
Patch set 8 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 7 months ago
Patch set 9 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Gerrit Code Review 7 months ago
Patch set 10 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80566
Updated by Stefan Bürk 3 months ago
- Status changed from Under Review to Rejected
Updated by Stefan Bürk 3 months ago
- Status changed from Rejected to Under Review
Updated by Ralf Hettinger 2 months ago
- Related to Bug #101927: TYPO3 Fluid Core ViewHelpers should not be declared "final class" added
Updated by Gabriel Kaufmann / Typoworx NewMedia 2 months ago
I also addressed this issue by #101927 and another use-case in #101929.
Before declaring these classes final it was possible to easily extend/override them for example to supress exceptions in Production-Environment for FAL missing image-exceptions or to extend functionality without having to duplicate the whole code.
I'm fine with declaring such classes final, BUT only if there is an abstract-class or trait defining the functionality for custom-implementations and usage in final class "interface" as well.