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