Allow defining injected services with PHP attributes

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Fixed failed commands on #2
Attached patch against Drupal 10.0.x

This still needs tests.

Should be postponed on 📌 [policy, no patch] Decide on a namespace for PHP Attribute classes Fixed .

+++ b/core/lib/Drupal/Core/DependencyInjection/ClassResolver.php
@@ -28,7 +29,7 @@ public function getInstanceFromDefinition($definition) {
       else {
-        $instance = new $definition();
+        $instance = $this->getInstanceFromAttributes($definition) ?? new $definition();
       }

Since we're already in an if/else block, this would read better if it was an extra block. The current change imposes two different levels of conditions.

Can I ask why this pattern was chosen?

  #[Services('entity_type.manager', 'cron')]
    protected EntityTypeManagerInterface $entityTypeManager,
    protected CronInterface $cron,

over something like in https://symfony.com/blog/new-in-symfony-6-1-service-autowiring-attributes, wherein each parameter is tagged:

public function __construct(
   #[SomeAttr(service: 'some_service')]
    protected EntityTypeManagerInterface $entityTypeManager,
   #[SomeAttr(service: 'some_service')]
    protected CronInterface $cron,
)

It seems like the latter option would be better for refactoring, make git diffs less disruptive.

+1 to #8 -- clear git diffs and simpler refactoring are both important.

I've just thought of a BIG DX enhancement this change would bring. At the moment it's a PITA to find the service name for a class if I am looking at a class where the service is injected. With a module it's not TOO bad -- I have to go look in MODULE.services.yml. But with core components, I have to dig up core.services.yml, find the class name in that HUGE file.

This proposal would mean I can see the service name in the class constructor -- easy!

(Changing title to make this easier to find.)

#8: Great reference! +1 for adopting the pattern.

Moreover, let's not invent another drupalism, but adopt that very attribute including its namespace.

title typo

This appears to be a duplicate of 📌 Allow plugin service wiring via constructor parameter attributes Needs work . Over there I propose using the Symfony #[Autowire] attribute syntax to replace the plugin factory method.

It turns out we can start using the Symfony #[Autowire] attribute already, see a single example in the attached patch.

I propose closing this as a duplicate of 📌 Use autowiring for core modules and services Needs work where I want to make this change across all of core.

#13: Great plan and totally makes sense. Sounds like postponing on the other though.
Making it so.

This seems like a great way to reduce boilerplate and help IDEs help us.

+1 #13 to follow #[Autowire] pattern
+1 #8 to tagging each parameter

See #13, we have paramter level #[Autowire].