[development] when we run out of characters

[Derek Wright]

On May 16, 2006, at 12:13 PM, Gerhard Killesreiter wrote:

> The number of hooks isn't all that big so you can easily work  
> around it.

but as we've recently agreed, the hooks can, do, and will change.   
when JonBob added "taxonomy_menu.module", there's no way he could  
have known in advance that hook_menu() was coming in the future.  we  
*certainly* aren't going to tie our own hands as to what hooks should  
be called in the future because of legacy modules with once-happy-now- 
conflicting names. ;)

On May 17, 2006, at 9:06 AM, Khalid B wrote:

> Any other objections?

my only objection to modulename_hook() is that it will be ugly and  
harder to read for the humans (e.g. on the admin/modules page, in the  
code itself, etc).  for example, the date field module for cck would  
become something like "fielddate".  if there's no other alternative,  
personally, i'd prefer fieldDate. *ducks*


module_name__hook()  is probably the cleanest option, and closest to  
existing code standards.  but, that requires changing *A LOT* of  
code. :(  too much code IMHO to be worth it, as "elegant" as it might  
be.

moduleName_hook() introduces case, but i think is fairly easy to  
read.  this has the nice benefit of only effecting modules that want  
multiple words in their own name, instead of forcing all code to change.

modulename_hook() is also ok from the code side, but then harder to  
read for the humans.

module_name_hook() is the status quo, and vulnerable to trouble down  
the road, especially since it's impossible to predict in advance what  
hooks are going to be in use N drupal versions from now.

as JonBob pointed out, it's not just a problem of core hooks, but  
function names in the "parent" modules (e.g. og.module) that have a  
bunch of "children" modules (og_*).  last time i brought this up,  
killes was quick to scold me with "this is not relevant to core". ;)   
at some level, that's true, in that there are no core modules that  
want/need multiple words in their name.  however, once CCK gets into  
core, this will be more of an issue (unless you want to open the new  
can of worms about grouping modules into classes that can be  
downloaded and administered together... something like propagating  
the module taxonomy in use on drupal.org directly into the  
administrative interface some how -- yikes).  and, in general, i'd be  
nice to have a documented, reasonable policy/convention for this, so  
that as contrib modules are developed that run into this problem,  
we'll know what to do.

personally, moduleName_hook()  (for the handful of modules that care,  
e.g og, cck, etc) isn't the end of the world, and requires much less  
work.  code may be gold, but grunt-work code is lead, IMHO.

-derek