avarab wrote:

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?

Astronouth7303 wrote:

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

Astronouth7303 wrote:

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

Astronouth7303 wrote:

Bug 6095 can make use of this as well.

Astronouth7303 wrote:

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.

Attached:

Astronouth7303 wrote:

Is it safe to close this bug as WONTFIX, in favor of hook-specific functions?