[development] when we run out of characters
drupal at dwwright.net
Wed May 17 21:55:20 UTC 2006
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
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.
More information about the development