Convert ContainerFactory and similar to use new self instead of static.

Oh hey past me, this is future me finding this through googling this error. :( I guess I should follow up with this.

right on. using "get_called_class" sounds like a red flag already but I wouldn't think this would affect the modules. We're going to be dealing with a lot of BC issues doing this though. I'm not really sure how to answer it more without a more concrete example though.

Here I am again... following a google search.

The before and after are pretty simple. As the title says, its just use new self instead of new static
Before:

class {
  /**
   * ......
   */

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('menu_link.static.overrides')
    );
  }

class {
  /**
   * ......
   */

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new self(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('menu_link.static.overrides')
    );
  }

Webform does that and I _hate_ it. It just makes the factory method into the constructor taking a container argument. It wanted to do this you might as well just pass the container to the native constructor. It may not be called a duck but it walks and talks like one because it is.

We rejected this injecting the container design and created ContainerInjectionInterface specifically to discourage users from doing it.
Of the top of my head(it was a long drawn out discussion across multiple issues and platforms)

1. It either explicitly breaks or significantly complicates test-ability
2. It obfuscates the classes dependencies.
3. Specific to this issue, it doesn't solve the problem it just tricks static analysis.

Honestly I think this design can be a lot worse then sending the container to the constructor because it doesn't follow then normal constructor mechanics and also creates _2_ constructors. I have got some webform handlers that extend some existing handlers and I've ended up having to completely copy the parent factory method, hack and rewrite it, then write a bunch of tests and pray the parent method never changes. All because there is some weird initialization stuff happening but its happening out side native constructors so you can't integrate with the normal parent::__construct() mechanics.

So, yeah... I keep going back and forth on new self but I'm _super_ against putting everything in the factory method.

I'm quite aware of how forms work, and my comments where directed at the ContainerInjectionInterface you're describing. The thing is, forms do have injection, the injection just isn't handled by the container. The ContainerInjectionInterface was carefully named and the documentation is very clear I think that its intended to inject into the constructor, not _be_ the constructor.

The reason injection happens this way boils down to basically two things.
1) No one liked writing a ton of service container logic and yaml to inject controllers. And it was clear a ton of unnecessary entries where going to end up on an already large and expensive to rebuild container. #2049159: Create a ControllerBase class to stop the boilerplate code madness
2) The alternative seemed to be to have a factory. This required the injection to be predefined or auto-wired and it turned out to be _very_ expensive and complicated to autowire injection on the fly (@see ReflectionFactory for an attempt with plugins).

The compromise was to have factories(or just inlined boiler plate) that delegated the injection part to this very limited method with _one_ purpose of being that glue to handle injection. We knew people might misuse the interface but every effort was made to make it clear not to.

So basically no. don't do that or the ghost of msonnabaum will hunt you down.