Last modified: 2011-03-13 18:05:20 UTC
The basic idea is in situations where each hook handles a specific item (such as an action), a hook may tell the hooking code this (by using it as its key in the $wgHooks[...] array (the array containing the hook functions for a specific hook; I'll use the term "hook array" when refering to this.) When the hook is called by the MW code, the caller passes the key (which is derived from the context, not the hook) to wfRunHooks(). wfRunHooks() checks the hook array for this key, and (if found) runs that hook before others. The primary reason for this would be a performance boost in situations where this is applicable. If the hook function returned false, then only one hook was called. Currently, the only hook that this is really useful on is 'UnknownAction', where the action would be the key. (Since each hook likely handles a specific action, hardcoded.)
So basically you want to add a value that'll be passed via $wgHooks that adds a priority to hooks, which you could do now by making sure the require's are in the right order?
(In reply to comment #1) > So basically you want to add a value that'll be passed via $wgHooks that adds a > priority to hooks, which you could do now by making sure the require's are in > the right order? Not exactly. It isn't a priority like 1-10. It's more like the hook is advertising to the hook code (wfRunHooks()) that it handles a specific item. It's useful when each hook handles a specific situation (eg, when the action is "egged"), and all the hooks are using the same variable. (eg, most of the 'UnknownAction' hooks check $action for their action.) Going with 'UnknownAction' action example, say you have 2 hooks, one that handles the "go" action, another that handles the "stop" action. You're hook array may look like this: $wgHooks['UnknownAction'] = array( 'go' => 'wfHandleGo', 'stop' => 'wfHandleStop' ); By the current system, one of them will be called every time (wfHandleGo). If this bug was implemented, wfRunHooks() would check for the action as a key in the array first, and (if it was 'go' or 'stop') call the appropriate hook before the other. Note that if the hook did not handle the action (it returned true), then the other hook would still be called. This would only change the order the hooks are called. It does not prevent hooks from being called or prevent more complex checking in the hook. This "key" would be optional for code calling wfRunHooks(). If the key is not passed, none of this is done.
I'm not sure this is necessary. UnknownAction is not exactly performance-intensive; it's only going to be called for the extra actions (rare code path), and if it has to make a few string comparisons before hitting the right one, that's unlikely to be much slower than an array lookup. It would probably make sense to replace UnknownAction with a key string => callback registration, though, and use that for the built-in actions as well.
(In reply to comment #3) > UnknownAction is not exactly performance-intensive; it's only going to be called for > the extra actions (rare code path), and if it has to make a few string comparisons > before hitting the right one, that's unlikely to be much slower than an array > lookup. No. But it's the only official hook that could use this. I thought of it while thinking about bug 4294, which would be called much more often. > It would probably make sense to replace UnknownAction with a key string => callback > registration, though, and use that for the built-in actions as well. I did that with the variable extensions (bug 3420), but someone had said I should use the hooking system instead.
Bug 4294 and bug 3420 are also cases where registration by requested type is what would make sense. $wgHooks provides filter chains, which don't really seem appropriate for these.
Bug 6095 can make use of this as well.
Created attachment 1829 [details] An implementation based on REL1_6 Adds a new function, wfCallHook(), which behaves similarly to wfRunHooks(), but will only call the specified hook. It's implemented almost identically to wfRunHooks() as well.
Is it safe to close this bug as WONTFIX, in favor of hook-specific functions?
