Hey,

A lot of components in core, for instance SpecialPages, API modules and Actions allow registering new components as follows:

$someList['some-name'] = 'YourHandlingClass';

The problem with this is that the extending code has no control over the instantiation of the handling object. So you can't inject any dependencies. That is more then a little bad design wise.

== Dependencies need to be pulled ==

Even when trying to properly design your handler, you are forced to have some static calls to obtain your dependencies (at least one if you have any dependencies) for no good reason. I don't see any way to get from under that. Furthermore this design simply encourages pulling in dependencies, so this is often done, regularly involving global state (not talking about global variables here, global state in general), thus seriously hurting the quality of the wider codebase.

== Cannot register a handler with state ==

You are forced to create different classes while different instances of a single class might suffice. Of course that just works in some cases, often you have to give up on the proper design altogether to make it work with the static registration system. This limitation seems to encourage abuse of inheritance as well, though it's certainly not the only thing doing that, and is not the focus of this mail.

Are there any ways for the mentioned components (SpecialPage, API and Action) to do have control of the lifecycle of the handling object that I am not aware of? Does anyone have plans to address these issues in our internal API, or has any work been done in this direction already?

Cheers

-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --