Consider marking some classes/functions @internal and find more convenient ways of dependency injection

Created on 4 October 2023, 9 months ago
Updated 21 October 2023, 8 months ago

Problem/Motivation

Coming out of πŸ“Œ Seriously consider respecting semantic versioning Active

Proposed resolution

  1. Use auto-wiring for services. Some of the code in Mailer.php on this branch is useful.
  2. Mark these constructors as @internal - they may change in a minor/patch release.
  3. Create an easier system for plug-in DI??

#3 is a bit of a radical idea, however it could be something like this:

  • New class DiPluginBase extending PluginBase
  • Protected static variable $service_ids array of strings.
  • Static function create() gets these services from the container, creates the object, then calls protected function inject() passing array of services keyed by id. In case of derived classes, combine the arrays from all levels of the class hierarchy.
  • Protected function inject() default implementation saves to protected variable $services.
  • Protected function service($id) gets the service - just like the Drupal::service() function however with DI.
  • Net code added to use a new service = add string to an array. No BC impact to derived classes.

Remaining tasks

User interface changes

API changes

Data model changes

πŸ“Œ Task
Status

Active

Version

1.0

Component

Code

Created by

πŸ‡¬πŸ‡§United Kingdom AdamPS

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

Comments & Activities

Production build 0.69.0 2024