Why not letting the base classes implement the interface and use the trait? So we don't have to touch all the MVC classes in each component to support auto wiring. It will be used only when the AutowireMVCFactory is used.

Why not letting the base classes implement the interface and use the trait? So we don't have to touch all the MVC classes in each component to support auto wiring. It will be used only when the AutowireMVCFactory is used.

I wanted to be safe and didn't thought deep enough about it. But yes the work is really annoying...

One of the issues could be that you can't remove the interface. So if you do it "right" in you extension and use the ConstructorAutowireInterface the buildObject does the work twice.
For example:

You have an CustomController, which extends the BaseController and implements the ConstructorAutowireInterface and have a constructor with __construct(DispatcherAwareInterface $dispatcher, LoggerAwareInterface $logger, CacheControllerFactoryAwareInterface $cacheFactory) everything is fine now.

If the BaseController implements the AbstractAutowireInterface the 3 interfaces will be set again after the construction. Not good performance wise, reflection is already expensive on it's own.

On the other side, it would allow us to add dependencies in the base classes at a later time without bothering extension developers to update the constructor...

I will test what will happen with the interface in the base classes.

IMHO, this is not a good approach, as it couples classes with the DI container through container-related interfaces. Consequently, service configuration becomes scattered across the codebase.

I would suggest defining autowiring configuration via simple arrays tagged with special "autowire" tags. For example:

// services/provider.php
$container->share('autowire_some_id', fn () => [
    BaseController::class => [
        '__construct'               => true, // enables contructor autowiring
        'setDispatcher'             => DispatcherAwareInterface::class,
        'setLogger'                 => LoggerAwareInterface::class,
        'setCacheControllerFactory' => CacheControllerFactoryAwareInterface::class,
    ],
    BaseDatabaseModel::class => [
        '__construct'               => true,
        'setDispatcher'             => DispatcherAwareInterface::class,
        'setDatabase'               => DatabaseAwareInterface::class,
        'setMVCFactory'             => MVCFactoryInterface::class,
        'setCacheControllerFactory' => CacheControllerFactoryAwareInterface::class,
   ],
]);
$container->tag('autowire_some_id', 'autowire');

On the first call, the AutowireFactory will collect all these arrays, merge them into one, and use it for wiring services.

IMHO, this is not a good approach, as it couples classes with the DI container through container-related interfaces. Consequently, service configuration becomes scattered across the codebase.

I would suggest defining autowiring configuration via simple arrays tagged with special "autowire" tags. For example:

// services/provider.php
$container->share('autowire_some_id', fn () => [
    BaseController::class => [
        '__construct'               => true, // enables contructor autowiring
        'setDispatcher'             => DispatcherAwareInterface::class,
        'setLogger'                 => LoggerAwareInterface::class,
        'setCacheControllerFactory' => CacheControllerFactoryAwareInterface::class,
    ],
    BaseDatabaseModel::class => [
        '__construct'               => true,
        'setDispatcher'             => DispatcherAwareInterface::class,
        'setDatabase'               => DatabaseAwareInterface::class,
        'setMVCFactory'             => MVCFactoryInterface::class,
        'setCacheControllerFactory' => CacheControllerFactoryAwareInterface::class,
   ],
]);
$container->tag('autowire_some_id', 'autowire');

On the first call, the AutowireFactory will collect all these arrays, merge them into one, and use it for wiring services.

Sounds really wrong on several levels to me, you don't want to define class depending information in another file (in this case the service provider) also you don't want to inject magic names into the container (the scalar things is a not so nice workaround for our legacy code base, because our container is a service locator not a "information" storage).

I see no benefit from this, yes the Container provides 2 new Interfaces which tells you (the cms) that it supports autowiring (actually for the container only the AbstractAutowireInterface is relevant because it needs to inject the dependencies).

Normally (if we could do it right from the beginning) the way would be to use the constructor and you don't need to do any manual declaration but our codebase is old and should be move into a new direction without breaking everything.

Never the less, thanks you for your feedback.

To some degree I share the concern of @voronkovich, that the dependency declaration functions are placed in the classes itself. What about using annotations for dependency declaration? Just a thought, not sure if it is of practical use.

I think annotations are not really helpful, you still need a method in the class to set the dependencies, mostly because a simple attribute has no "value" (for example holding the setter method). for this I think we need properties. makes it a bit more complex.
But maybe I'm wrong with how to use the annotations.

Beside that you need to rebuild the inheritance manually and reflect each parent class, which is expensive.
I would like to use more attributes or properties in joomla but it should make the code nicer

Also I might have missed the point where the class is no longer responsible for the needed dependencies.

ymmv

Why not letting the base classes implement the interface and use the trait? So we don't have to touch all the MVC classes in each component to support auto wiring. It will be used only when the AutowireMVCFactory is used.

I implemented the interface and I think it's a good idea and works as expected.