Contrib.social

Deprecate passing extra parameters to __construct() to prepare for 3.0.x

Open on Drupal.org →
Created on 8 April 2025, 28 days ago

Problem/Motivation

As the module evolves, we can expect new services to be added, service dependencies to change, etc.

The "classic" way to inject dependencies into a class is to use arguments to the constructor (i.e.: public function __construct($dependency1) { $this->dependency1 = $dependency1; }. But if you want to add a new dependency, or delete a dependency, then you have to change the function signature of the constructor (which is often public).

Technically, Drupal core's backwards-compatibility policy considers service object constructors to be @internal → ; however, in practice, changing the signature of service object constructors can occasionally cause fatal errors after a module upgrade, which isn't ideal.

Fortunately, PHP provides an alternate way to inject dependencies that doesn't involve changing function signatures, and thus avoids fatal errors on module upgrades...

class Foo {
  /* Omit the constructor, i.e.: to inherit it from its base class */
  public static function create(ContainerInterface $container) {
    $instance = new static():
    $instance->dependency1 = $container->get('dependency1');
    return $instance;
  }
}

... to distinguish these from the classic-style of dependency injection, this issue will refer to this as the "new-style of dependency injection".

At time-of-writing, the 2.x branch of structure_sync has 4 instances of classic-style dependency injection:

  1. \Drupal\structure_sync\Controller\MenuLinksController::__construct()
  2. \Drupal\structure_sync\Form\BlocksSyncForm::__construct()
  3. \Drupal\structure_sync\Form\MenuSyncForm::__construct()
  4. \Drupal\structure_sync\Form\TaxonomiesSyncForm::__construct()

There is talk of creating a 3.0.x branch in ✨ Drop support for D8, D9, D10.0-10.3 Active .

We can't change constructor signatures in the 2.x branch; but we can prepare to change the signatures in the 3.0.x branch by deprecating the use of classic-style dependency injection.

Proposed resolution

For the 4 services listed above...

  1. start using the new-style dependency injection for those services; and;
  2. stop doing anything with the parameters passed into those constructors, and mark those parameters as deprecated

... this will allow us to remove those constructors in a 3.0.x branch.

Remaining tasks

  1. Write a merge request to start using new-style dependency injection and deprecate classic-style dependency injection in the 2.x branch
  2. Review and feedback
  3. RTBC and feedback
  4. Commit
  5. Release a 2.x version
  6. File a follow-up ticket for the 3.0.x branch

User interface changes

None.

API changes

None.

Data model changes

None.

✨ Feature request
Status

Active

Version

2.0

Component

Code

Created by

🇨🇦Canada mparker17 UTC-4

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024