@xabbuh following your comment, how do you plan to deprecate this method now?

What about a deprecation message + BC layer here:

here:

and here:

IMO we no longer need to deprecate the method.

To elaborate a bit more on this: The new interface extends the existing FormTypeExtensionInterface. If we do not deprecate anything, we know that the extension will have the getExtendedType() method. And if we extend the AbstractTypeExtension class, we even do not have to care about this method as it is then provided by the base class in case we implement the new interface.

And if we do not implement the new interface, nothing changes at all as we still need to implement the getExtendedType() method like we had to do before.

My concern about getExtendedType() in 5.0 is that we have two methods almost equals (both return the type to extend) but the new one is much better, it also allows us autoconfigure the type extension, great! So when will it "getExtendedType()" be used in 5.0 userland?

My point, we'll have two choice to return the type to extend for 5.0+, the first one is a bad choice if the second one is better, good condition to deprecate it IMO.

Plus, if we keep getExtendedType() in AbstractTypeExtension forever, IDEs like PhpStorm will not be able to autodetect the missing method to implement anymore, this will be seen in the exception on complication time, worst DX then.

At the end: I'd like (for 5.0 o 6.0) to see the static version in FormTypeExtensionInterface instead of the current getExtendedType(), is it possible in long term? I'm dreaming, probably a nightmare :)

getExtendedType() will only there for BC concerns. But I am not convinced it's really necessary to deprecate it if the code will still work fine. That way we would save maintainers some hassle with updating their code.

@yceruto getExtendedType() is now deprecated in the interface

With getExtendedType deprecated, all the calls that are still done to it need to use the new static method instead when it exists. E.g. in AbstractExtension that yceruto mentioned. And it should also trigger a deprecation message or is this done automatically?

you must throw an exception here, telling to implement the other method or to override this one, because returning null is not allowed.

This validation prevents to use different instances of the same class to be used for different extensions. So it prevents the only advantage of extended_type attribute that I mentioned in #24530 (comment) as people will be forced to implement the method in 5.0 when its part of the interface. So they need to return an empty array and then overwrite it with the service attribute.

IMO we do not need the validation anymore as now both the registration and implementation uses getExtendedTypes. So there should not be a mismatch anymore unless you wire something wrong manually.

class FooBarTypeExtension extends AbstractTypeExtension
{
    public function __construct(string $type)
    {
    }

    public static function getExtendedTypes(): iterable
    {
        return array(
            FooType::class,
            BarType::class,
        );
    }
}

App\Form\FooBarTypeExtension:
    arguments: ['foo']
    tags:
        - name: form.type_extension
          extended_type: FooType

App\Form\FooBarTypeExtension:
    arguments: ['bar']
    tags:
        - name: form.type_extension
          extended_type: BarType

Do I understand correctly that you have something like this in mind?

Yes. By returning both types from getExtendedTypes, it actually works even with the validation. So I'm fine keeping it like this. But I think it would make more sense to remove the validation as it should not matter what is returned by getExtendedTypes if you set the extended_type attribute (and you might not even know that in advance if you create a dynamic form extension).

I wonder if we shouldn't rather deprecate the extended_type attribute too instead I could imagine that using it adds more confusion than an implementation where getExtendedTypes() is the single source of truth.

I agree that it potentially is complicating things for no real use-case. But I also like that it allows to configure extensions dynamically via DI (instead of hardcoding it into a class). As I said in #24530 (comment), its similar to the command attribute of the console.command tag. So it would be consistent to keep it. But I would not object to deprecate it as well.

Let's keep it for now. We can still consider to deprecate it later when we noticed that it adds too much confusion.