Hey,
After grepping for setHook, it turns out that an extension like Maps, that
has zero matches, sets parser hooks indirectly via Validator extension.
Indeed. Innovation cannot happen without change. I'd argue that deriving from the ParserHook class makes it easier to find parser hooks, but this has quite little to do with my inclusion request.
It seems to set a hook for <display_map> but actually sets it for <display
map> (Why??)
It sets {{#display_map}} and <display map>. That's the desired behaviour of this parser hook.
It makes things more complex.
It makes creating parser hooks easier by hiding most of the complexity that comes with handling their parameters. How does it make things more complex?! The code itself is of course as complex as it needs to be to handle various use cases. Arguing against that is the same as arguing against the Html, Http and similar classes, and is quite absurd IMO.
As for your criticism on how I choose to register ParserHook classes: due to limitations in the current version of PHP I could not fully do what I wanted there, and settled for the most programmatic solution I saw. If you have a better approach, feel very free to share it with me, or fix it yourself. This really is just an implementation detail, and again has little to do with my inclusion request.
Cheers
-- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --