Hook naming conflicts: what happens?

Question

If two modules implementing two separate hooks ended up with functions with the same name, could that cause a conflict or problem?

a.module

/**
 * Implements hook_a_b().
 */
function a_a_b() {}

b.module

/**
 * Implements hook_b().
 */
function b_b() {}

c.module

/**
 * Implements hook_a_b().
 */
function c_a_b() {}

c_a.module

/**
 * Implements hook_b().
 */
function c_a_b() {}

Does the scoping prevent that from causing a problem, even though the functions have the same names?

What happens if two modules declare the same hooks, even though they follow the naming scheme and the hook names contain the module names?

a.module

/**
 * Implements hook_a_b_c().
 */
function a_a_b_c() {}

a_b.module

/**
 * Implements hook_a_b_c().
 */
function a_b_a_b_c() {}

x.module

/**
 * Implements hook_a_b_c().
 *
 * It's not clear which of the two hooks this actually implements.
 */
function x_a_b_c() {}

Answer 1

Hooks are plain PHP functions that follow a specific name schema. As such, the same function name cannot be used from two modules. Furthermore, Drupal is not able to understand if c_a_b() is the implementation of hook_a_b() done from c.module, or the implementation of hook_b() done from c_a.module. To answer the question, yes, there would be conflicts and (in the case both the modules are installed) PHP errors.

Use something other than a single underscore for hook namespacing aims to not use a single underscore to separate the module name from the hook name, for example two underscores. Doing so, c__a_b() would be an implementation of hook_a_b() done from c.module, and it would not be confused with c_a__b(), the implementation of hook_b() done from c_a.module.
There is also Module names should not contain an underscore, which would avoid any ambiguity with c_a_b(). As underscores would not be allowed in module machine names, c_a_b() could just be the implementation of hook_a_b() done from c.module. (That feature request is set to closed (won't fix); at the moment, it's not going to be implemented.)

As for two modules invoking the same hook for different purposes and/or with different parameters, that is going to cause conflicts and errors.
The code invoking hooks calls a function basing on its name (<module>_<hook name>) directly passing the arguments to the function. If the arguments don't match the function parameters, PHP will raise an error; if the arguments match the function parameters, there will be other errors, as a hook supposes to be invoked in a specific moment, as described in the hook documentation. Imagine what would happen if a module would invoke hook_user_delete() after a user deleted a node; the modules implementing it would delete the data associated to that account from their database tables, since hook_user_delete() is documented to be invoked before a user account is deleted, not any data associated to the deleted node.

In both the cases, the only solution is naming hooks and modules in a way to avoid conflicts.

As per https://www.drupal.org/project/hook, that URL returns a 403 error because there is an unpublished project. (I can visit the project page because I have more permissions than what other people normally have on drupal.org.)

The project has been created to avoid somebody would name a project Hook.

Answer 2

All hooks are in the global scope; PHP doesn’t allow two functions to have the same name in the global scope (it wouldn’t be able to distinguish which the intended callee was). It will exit with a fatal error during parsing.

Yes, there is a definite potential for conflicts in the style you mentioned, but I doubt you’ll see it happen that often in the real world.

I’m not really sure what you mean by the 2nd example. Modules don’t “declare” hooks as such, not in any programmatically significant way at least, they just invoke them (and hopefully document them in an include api file).

There’s the hook_hook_info concept, but that’s just for allowing hooks to be implemented in an automatically included sub-file of a module.