On Wed, 03 Apr 2013 23:43:20 -0700, Dmitriy Sintsov questpc@rambler.ru wrote:
4 Апрель 2013 г. 10:11:44 пользователь Daniel Friesen (daniel@nadir-seen-fire.com) написал: On Wed, 03 Apr 2013 22:23:41 -0700, Dmitriy Sintsov questpc@rambler.ru wrote:
4 Апрель 2013 г. 9:16:49 пользователь Jeroen De Dauw >>
(jeroendedauw@gmail.com) написал:
Hey,
I see no reason to get rid of the hooks class.
Given you also do not understand why I think the comment is funny, I recommend you read up on why writing static code is harmful. And on
how
global state can hide in static "classes".
We use static classes other places in core.
https://yourlogicalfallacyis.com/bandwagon In almost all such cases I have seen in core this kind of use of
static >> is
bad.
And there's no reason to revert to hideous functions like we had
before. No one is suggesting that. Cheers --
Why the hooks should not be static? Multi-site (farm) built-in
support > in core without $wgConf? Common page table across multiple sites?
Dmitriy
How do you envision non-static hooks working and supporting multiple wikis?
If hooks will be non-static, should the hooks become the members of RequestContext, maybe? Dmitriy
No, hooks are not a request thing. Hooks are at a level more global than the request context and are also relevant in places where there is no request context such as maintenance scripts, parsing, and things that should be isolated and not tied to a request.
RequestContext also uses the hook system.
Think of it this way. A request context is for a request. Pretending we handle multiple requests in one script run we would have a separate request for each. However hooks are something done at the level of extensions. The level this part of extensions are part of is environment init, along with the loading of executable code into memory. You do this once at the start of the script execution. Not each request. If we were to run MediaWiki in a daemon like way of serving requests like python and ruby support where the application is loaded into a process and request after request is passed to it. We'd still load hooks once at the start not once per request. (and we'd probably kill off the lame stuff we have to do to avoid stuff from being initialized when it's not used in a particular request since in a daemon it's only initialized once).