[development] module_exists vs. functions_exists?

Earnie Boyd earnie at users.sourceforge.net
Mon Jun 23 16:28:08 UTC 2008


Quoting Aaron Winborn <winborn at advomatic.com>:

> As we don't have public and private scope,

But we do, really.  Sure it's global but we do have the ability to 
create standards that set a private scope using the module name and 
prefixing the module name with an _ (underscore) character for private 
module use.

> I think that in practice, failing a better method, module_invoke 
> should be the safer way to do this.

As I've stated already, module_invoke is meant to be used to invoke 
hooks.  Using module_invoke for anything else is confusing and can 
cause issues should module_invoke change its methods.

> In my modules, if I have functionality I don't want to expose, I 
> prefix it with an underscore: _module_name_private_api.

This should be the case for all private symbols.  This ensures that 
some new hook isn't going to cause you to have to rename your private 
functions.  Stating this brings another issue with the Drupal hook 
system in that my naming of my module static function isn't namespace 
safe.  For example mymodule_myfunction becomes invoked when Drupal or 
some other module adds a hook and invokes all implementations of 
hook_myfunction which isn't what I meant for mymodule_myfunction.  This 
is most easily avoided by using a static class and defining all 
functions for the module within the class.  However, this should only 
happen with a new version of Drupal and we have to convert the modules 
to use the new versions anyway; but, how many of us check our function 
names as being a new hook?

> Thus, in my hypothetical contract, module_name_public_api would be 
> safe to be called using module_invoke, at least within a core 
> version, and would at least guarantee the same arguments and expected 
> result, even if the inner codebase changed. Whereas the private 
> function would have no such guarantee, and modules invoking it do so 
> at the risk that the function's arguments may change, or it may even 
> cease to exist.
>

No such guarantee for public function can be made and private functions 
should remain private for the reason you suggest.  Another reason to 
use classes for the module functions; if I mark the function private, 
it truly is.

> Additionally, module_invoke would allow for optional dependence, 
> which is generally where I use that anyway.
>

Not anymore than using function_exists.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/



More information about the development mailing list