Problem/Motivation
Drupal currently has two main ways of getting the service discovery container:
- \Drupal
- ContainerInjectionInterface or similar 'proper' injection pattern.
\Drupal is intended to be used by legacy procedural code which does not have an injection path.
Other service discovery should follow the inversion-of-control principle where services are injected into consumer classes without keeping a reference to the container itself. This principle is satisfied by the ContainerInjectionInterface pattern, and is also generally satisfied by the arguments property of the service definition file.
Proposed resolution
- #2380293: Properly inject services into ModuleInstaller discovered that some re-thinking is required for the 'lazy' status of some services.
\Drupaldeferred instantiation of some services until needed, and removing it led to large memory usage. So: Discover which services need deferred instantiation as we go along. - Convert controllers/forms which use service traits, such as
StringTranslationTrait. One issue per trait. - Make changes per
\Drupalservice method. There will be some patch conflicts based on which lands first. Since we're injecting the dependencies, we'll probably end up changing the constructor per patch and that will lead to rerolls. We should also look for the service name itself, so we can convert\Drupal::get()for the equivalent service. - We do this for non-test code under this issue.
- Then we can concentrate on making the tests happen: #2066993: Use \Drupal consistently in tests For instance, the majority of occurrences of
\Drupal::root()appear in tests. - #2066993: Use \Drupal consistently in tests suffers a bit from the same reviewability problem as this one, but could be rescoped to work per-method. There would be fewer patch conflicts, because the container is injected into the test class whole.
- Then the plan all goes to heck when we get to
\Drupal::get()and it's utter chaos. :-)