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.
--