- 🇫🇷France andypost
In core we've held off from using final on classes because of the idea that final limits extensibility and a key feature is extensibility.
However there are cases where we've defined specific types of classes in core as not being extensible and @internal by default. These include:
See https://www.drupal.org/core/d8-bc-policy →
However people are extending these in contrib and custom code and then when we make changes to the constructors things break. For example:
https://www.drupal.org/project/drupal/issues/2594425 →
and then
https://www.drupal.org/project/menu_block/issues/2968049 →
Use final instead of an implicit @internal. Put in another way we need to prioritise composition over inheritance. So a plugin that wants to borrow functionality from another plugin could create that plugin in it's constructor and then use that object. See
#2968049-18: Dependency Injection issue →
as an example.
Making this change is likely to shift some costs from future maintenance to the here-and-now but in the long run it means that core upgrades to major and minor releases can be done with more confidence because our conventions have moved from wishful thinking to language constructs.
final is bad.None
None :) everything is already implicitly @internal
None
This is Drupal 9 only change.
Active
11.0 🔥
Last updated
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
