Hi, In building some contrib modules that interact with other modules I often find myself writing something like: if (module_exists('module_name')) { $foo = module_name_api_function($bar); } This seems to be pretty common across core and contrib. I'd even call it standard. Another option would be: if (function_exists('module_name_api_function')) { $foo = module_name_api_function($bar); } The benefit of the second format is that if/when module_name's maintainer decides to rewrite module_name and change all their functions then my module may simply stop interacting with it rather than failing on a function not found error. The benefit of the first format is that it fails quickly and is likely to generate a bug report with a very clear solution. Thoughts? Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com
Come Drupal 7, you'll want to use drupal_function_exists() specifically so that it can lazy-load the function if needed. I suppose that's a strike in favor of using function_exists() for now so that your logic is already setup for that. On Sunday 22 June 2008 4:36:46 pm Greg Knaddison - GVS wrote:
Hi,
In building some contrib modules that interact with other modules I often find myself writing something like:
if (module_exists('module_name')) { $foo = module_name_api_function($bar); }
This seems to be pretty common across core and contrib. I'd even call it standard.
Another option would be:
if (function_exists('module_name_api_function')) { $foo = module_name_api_function($bar); }
The benefit of the second format is that if/when module_name's maintainer decides to rewrite module_name and change all their functions then my module may simply stop interacting with it rather than failing on a function not found error.
The benefit of the first format is that it fails quickly and is likely to generate a bug report with a very clear solution.
Thoughts?
Thanks, Greg
-- Larry Garfield larry@garfieldtech.com
What happens when mymodule is enabled, but because of the registry (or even in D6, the "file" argument in hook_menu()) is not loading the function you assume exists just because mymodule is enabled (and module_exists('mymodule') returns TRUE? I guess function_exists() would be path dependent now? Please correct me. On Sun, Jun 22, 2008 at 5:46 PM, Larry Garfield <larry@garfieldtech.com> wrote:
Come Drupal 7, you'll want to use drupal_function_exists() specifically so that it can lazy-load the function if needed. I suppose that's a strike in favor of using function_exists() for now so that your logic is already setup for that.
On Sunday 22 June 2008 4:36:46 pm Greg Knaddison - GVS wrote:
Hi,
In building some contrib modules that interact with other modules I often find myself writing something like:
if (module_exists('module_name')) { $foo = module_name_api_function($bar); }
This seems to be pretty common across core and contrib. I'd even call it standard.
Another option would be:
if (function_exists('module_name_api_function')) { $foo = module_name_api_function($bar); }
The benefit of the second format is that if/when module_name's maintainer decides to rewrite module_name and change all their functions then my module may simply stop interacting with it rather than failing on a function not found error.
The benefit of the first format is that it fails quickly and is likely to generate a bug report with a very clear solution.
Thoughts?
Thanks, Greg
-- Larry Garfield larry@garfieldtech.com
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
Come Drupal 7, you'll want to use drupal_function_exists() specifically so that it can lazy-load the function if needed. I suppose that's a strike in favor of using function_exists() for now so that your logic is already setup for that.
Right ... For D6 and below, module_invoke() does the if (function_exists()) for you. Some people prefer that pattern.
Ah, didn't realize it was changing :( Guess I need to read up on this issue. ----- Original Message ----- From: "Moshe Weitzman" <weitzman@tejasa.com> To: development@drupal.org Sent: Sunday, June 22, 2008 7:28:04 PM GMT -05:00 US/Canada Eastern Subject: Re: [development] module_exists vs. functions_exists?
Come Drupal 7, you'll want to use drupal_function_exists() specifically so that it can lazy-load the function if needed. I suppose that's a strike in favor of using function_exists() for now so that your logic is already setup for that.
Right ... For D6 and below, module_invoke() does the if (function_exists()) for you. Some people prefer that pattern.
Quoting Greg Knaddison - GVS <Greg@GrowingVentureSolutions.com>:
Hi,
In building some contrib modules that interact with other modules I often find myself writing something like:
if (module_exists('module_name')) { $foo = module_name_api_function($bar); }
This seems to be pretty common across core and contrib. I'd even call it standard.
Another option would be:
if (function_exists('module_name_api_function')) { $foo = module_name_api_function($bar); }
The benefit of the second format is that if/when module_name's maintainer decides to rewrite module_name and change all their functions then my module may simply stop interacting with it rather than failing on a function not found error.
The benefit of the first format is that it fails quickly and is likely to generate a bug report with a very clear solution.
Thoughts?
I would rather ask the interacting modules to insert a MODULE_FOO_VERSION and check for the constant being defined and defined to the version you expect. The module_exists function used with function_exists as you suggest is a good fall back for not having MODULE_FOO_VERSION. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie Boyd wrote:
I would rather ask the interacting modules to insert a MODULE_FOO_VERSION and check for the constant being defined and defined to the version you expect. The module_exists function used with function_exists as you suggest is a good fall back for not having MODULE_FOO_VERSION. Agreed. I recently had an issue where a module I depended on was upgraded and this resulted in my module failing. Being able to specify that I was expecting a specific version of the module would have helped troubleshoot the issue alot quicker.
Jonathan
Agreed. I recently had an issue where a module I depended on was upgraded and this resulted in my module failing. Being able to specify that I was expecting a specific version of the module would have helped troubleshoot the issue alot quicker.
Jonathan
There's a patch here which does exactly that, just waiting to be reviewed: http://drupal.org/node/211747 Nat
I usually use the following pattern: if (module_exists('module_name')) { $foo = module_invoke('module_name', 'api_function', $bar); } ----- Original Message ----- From: "Greg Knaddison - GVS" <Greg@GrowingVentureSolutions.com> To: development@drupal.org Sent: Sunday, June 22, 2008 5:36:46 PM GMT -05:00 US/Canada Eastern Subject: [development] module_exists vs. functions_exists? Hi, In building some contrib modules that interact with other modules I often find myself writing something like: if (module_exists('module_name')) { $foo = module_name_api_function($bar); } This seems to be pretty common across core and contrib. I'd even call it standard. Another option would be: if (function_exists('module_name_api_function')) { $foo = module_name_api_function($bar); } The benefit of the second format is that if/when module_name's maintainer decides to rewrite module_name and change all their functions then my module may simply stop interacting with it rather than failing on a function not found error. The benefit of the first format is that it fails quickly and is likely to generate a bug report with a very clear solution. Thoughts? Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com
Aaron Winborn wrote:
$foo = module_invoke('module_name', 'api_function', $bar);
I understand that this may be a bit safer, but it has a drawback o its own. Coder won't catch these when it's time to upgrade to a new core version. Nancy No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.1/1513 - Release Date: 6/22/2008 7:52 AM
Quoting Aaron Winborn <winborn@advomatic.com>:
I usually use the following pattern:
if (module_exists('module_name')) { $foo = module_invoke('module_name', 'api_function', $bar); }
I think you're correct in using this; but only for hooks. You've stated 'api_function' when it is actually the 'hook'. And if mymodule_myfunction isn't a hook should we be using module_invoke to do the call? No, we should call the function directly. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
$foo = module_invoke('module_name', 'api_function', $bar);
...without module_exists() is sufficient. module_invoke() invokes module_hook(), which in turn checks for function_exists(). Also, module_invoke() is not limited to Drupal hooks / API callbacks. If the returned results of call_user_func_array() work for your particular implementation, this is the best approach for each module that wants to integrate with another, optionally installed module in contrib. @see http://api.drupal.org/api/function/module_invoke/5 @see http://api.drupal.org/api/function/module_hook/5 Daniel
Quoting "Daniel F. Kudwien" <news@unleashedmind.com>:
Also, module_invoke() is not limited to Drupal hooks / API callbacks. If the returned results of call_user_func_array() work for your particular implementation, this is the best approach for each module that wants to integrate with another, optionally installed module in contrib.
While using module_invoke for things other than hooks today, I do not think we should recommend it since the purpose of module_invoke is to invoke the hook. Using module_invoke for more than its intended purpose is confusing and may cause issues in the future should module_invoke change its ways. Module_invoke is more like calling an object function while executing the function directly is more like executing a static class function. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
While using module_invoke for things other than hooks today, I do not think we should recommend it since the purpose of module_invoke is to invoke the hook. Using module_invoke for more than its intended purpose is confusing and may cause issues in the future should module_invoke change its ways. Module_invoke is more like calling an object function while executing the function directly is more like executing a static class function.
Earnie
For what it's worth: Drupal's core API changes only between major versions. As long as we're speaking of D5 and D6, and of contrib modules for D5 and D6, I would repeat my previous recommendation to a) remove unnecessary module_exists()/function_exists() code bloats, and b) manifest a best practice that can be dealt with in the module upgrade docs for D7 and/or beyond. Until there is not a better API method, it is absolutely safe to use module_invoke(). Look, it's still there: http://api.drupal.org/api/function/module_invoke/7 Daniel
Quoting "Daniel F. Kudwien" <news@unleashedmind.com>:
While using module_invoke for things other than hooks today, I do not think we should recommend it since the purpose of module_invoke is to invoke the hook. Using module_invoke for more than its intended purpose is confusing and may cause issues in the future should module_invoke change its ways. Module_invoke is more like calling an object function while executing the function directly is more like executing a static class function.
Earnie
For what it's worth: Drupal's core API changes only between major versions. As long as we're speaking of D5 and D6, and of contrib modules for D5 and D6, I would repeat my previous recommendation to a) remove unnecessary module_exists()/function_exists() code bloats, and b) manifest a best practice that can be dealt with in the module upgrade docs for D7 and/or beyond. Until there is not a better API method, it is absolutely safe to use module_invoke().
Look, it's still there: http://api.drupal.org/api/function/module_invoke/7
For D7 it has already been stated that you want to use http://api.drupal.org/api/function/drupal_function_exists/7 so that the modules files are loaded as necessary. Module_invoke is not the correct thing to do unless you want to invoke hooks. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
In Drupal 7, module_invoke uses module_hook uses drupal_function_exists. I don't see why you should not use module_invoke to call API functions. -- Frando Earnie wrote:
Quoting "Daniel F. Kudwien" <news@unleashedmind.com>:
While using module_invoke for things other than hooks today, I do not think we should recommend it since the purpose of module_invoke is to invoke the hook. Using module_invoke for more than its intended purpose is confusing and may cause issues in the future should module_invoke change its ways. Module_invoke is more like calling an object function while executing the function directly is more like executing a static class function.
Earnie
For what it's worth: Drupal's core API changes only between major versions. As long as we're speaking of D5 and D6, and of contrib modules for D5 and D6, I would repeat my previous recommendation to a) remove unnecessary module_exists()/function_exists() code bloats, and b) manifest a best practice that can be dealt with in the module upgrade docs for D7 and/or beyond. Until there is not a better API method, it is absolutely safe to use module_invoke().
Look, it's still there: http://api.drupal.org/api/function/module_invoke/7
For D7 it has already been stated that you want to use http://api.drupal.org/api/function/drupal_function_exists/7 so that the modules files are loaded as necessary. Module_invoke is not the correct thing to do unless you want to invoke hooks.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- View this message in context: http://www.nabble.com/module_exists-vs.-functions_exists--tp18059424p1809225... Sent from the Drupal - Dev mailing list archive at Nabble.com.
Quoting Frando <frando2@unbiskant.org>:
In Drupal 7, module_invoke uses module_hook uses drupal_function_exists. I don't see why you should not use module_invoke to call API functions.
As I have already stated it isn't the defined use of the function. The defined use of the function is to execute hook implementations. If it is used for anything else then confusion will happen and perhaps cause for a lot of frustration in maintenance. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Jun 24, 2008, at 10:48 AM, Earnie Boyd wrote:
Quoting Frando <frando2@unbiskant.org>:
In Drupal 7, module_invoke uses module_hook uses drupal_function_exists. I don't see why you should not use module_invoke to call API functions.
As I have already stated it isn't the defined use of the function. The defined use of the function is to execute hook implementations. If it is used for anything else then confusion will happen and perhaps cause for a lot of frustration in maintenance.
I don't buy it. This looks like an excellent use of an existing function that does exactly what is called for. What defines a 'hook' anyway? Is a function not a hook if only one module implements it? Would it be such a stretch to think of every function as a hook to be invoked in multiple different ways? -Mike __________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net 503.488.5433 714.356.0168 cell 949.200.7670 fax
On Tue, Jun 24, 2008 at 7:50 PM, Michael Prasuhn <mike@mikeyp.net> wrote, about module_invoke():
I don't buy it. This looks like an excellent use of an existing function that does exactly what is called for. What defines a 'hook' anyway? Is a function not a hook if only one module implements it? Would it be such a stretch to think of every function as a hook to be invoked in multiple different ways?
It doesn't make sense to use module_invoke() in the stated case (calling a specific API function of a module). module_invoke() does not do any error checking, and it does not report anything useful. You should call drupal_functon_exists() directly and act accordingly in case of errors. Using module_invoke() here would be bad practice at best, but could also be dangerous. Damien Tournoud
On Jun 24, 2008, at 11:32 AM, Damien wrote:
On Tue, Jun 24, 2008 at 7:50 PM, Michael Prasuhn <mike@mikeyp.net> wrote, about module_invoke(): I don't buy it. This looks like an excellent use of an existing function that does exactly what is called for. What defines a 'hook' anyway? Is a function not a hook if only one module implements it? Would it be such a stretch to think of every function as a hook to be invoked in multiple different ways?
It doesn't make sense to use module_invoke() in the stated case (calling a specific API function of a module). module_invoke() does not do any error checking, and it does not report anything useful. You should call drupal_functon_exists() directly and act accordingly in case of errors.
Using module_invoke() here would be bad practice at best, but could also be dangerous.
Once again, I don't buy it. If you have to switch off of whether the function exists, then by all means do that. But for Drupal 6 development I see no issue with using module_invoke. If you can't be bothered to test your code to make sure what it depends on is there, then your code has deeper issues than the method used to interface with another API. -Mike __________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net
module_invoke() is used to call core API functions in a special core API class called hooks. If your function is not part of the core API, then using module_invoke to call it is misleading. Misleading code is a maintenance problem. Some day, the functionality of module_invoke() may change and not work correctly to call random contributed module functions. It will always work to call hooks, however. Hence, by definition, it is wrong to use it for a purpose it was not meant. On Tue, Jun 24, 2008 at 2:31 PM, Michael Prasuhn <mike@mikeyp.net> wrote:
On Jun 24, 2008, at 11:32 AM, Damien wrote:
On Tue, Jun 24, 2008 at 7:50 PM, Michael Prasuhn <mike@mikeyp.net> wrote, about module_invoke(): I don't buy it. This looks like an excellent use of an existing function that does exactly what is called for. What defines a 'hook' anyway? Is a function not a hook if only one module implements it? Would it be such a stretch to think of every function as a hook to be invoked in multiple different ways?
It doesn't make sense to use module_invoke() in the stated case (calling a specific API function of a module). module_invoke() does not do any error checking, and it does not report anything useful. You should call drupal_functon_exists() directly and act accordingly in case of errors.
Using module_invoke() here would be bad practice at best, but could also be dangerous.
Once again, I don't buy it. If you have to switch off of whether the function exists, then by all means do that. But for Drupal 6 development I see no issue with using module_invoke. If you can't be bothered to test your code to make sure what it depends on is there, then your code has deeper issues than the method used to interface with another API.
-Mike
On Wed, Jun 25, 2008 at 1:02 AM, Chris Johnson <cxjohnson@gmail.com> wrote:
module_invoke() is used to call core API functions in a special core API class called hooks. If your function is not part of the core API, then using module_invoke to call it is misleading. Misleading code is a maintenance problem. Some day, the functionality of module_invoke() may change and not work correctly to call random contributed module functions. It will always work to call hooks, however. Hence, by definition, it is wrong to use it for a purpose it was not meant.
On Tue, Jun 24, 2008 at 2:31 PM, Michael Prasuhn <mike@mikeyp.net> wrote:
On Jun 24, 2008, at 11:32 AM, Damien wrote:
On Tue, Jun 24, 2008 at 7:50 PM, Michael Prasuhn <mike@mikeyp.net> wrote, about module_invoke(): I don't buy it. This looks like an excellent use of an existing function that does exactly what is called for. What defines a 'hook' anyway? Is a function not a hook if only one module implements it? Would it be such a stretch to think of every function as a hook to be invoked in multiple different ways?
It doesn't make sense to use module_invoke() in the stated case (calling a specific API function of a module). module_invoke() does not do any error checking, and it does not report anything useful. You should call drupal_functon_exists() directly and act accordingly in case of errors.
Using module_invoke() here would be bad practice at best, but could also be dangerous.
Once again, I don't buy it. If you have to switch off of whether the function exists, then by all means do that. But for Drupal 6 development I see no issue with using module_invoke. If you can't be bothered to test your code to make sure what it depends on is there, then your code has deeper issues than the method used to interface with another API.
-Mike
I agree with Chris johnson, I would say even more, I would propose a modification to module_invoke to not allow calling API functions other than hooks :)
Quoting Chris Johnson <cxjohnson@gmail.com>:
module_invoke() is used to call core API functions in a special core API class called hooks. If your function is not part of the core API, then using module_invoke to call it is misleading. Misleading code is a maintenance problem. Some day, the functionality of module_invoke() may change and not work correctly to call random contributed module functions. It will always work to call hooks, however. Hence, by definition, it is wrong to use it for a purpose it was not meant.
Correct, and stating it like Chris has said we can go as far to say that module_invoke is a private core function reserved for the use of the hooks class. Modules themselves should not use it unless the module has created a hook and needs to call other modules implementations of that hook. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Then if developers (such as myself, but not only myself) are using module_invoke as a safe method to invoke a module's "public" API function, then perhaps we need to create a comparable safe and easy method, rather than calling said developers "lazy". (The lazy method, indeed, would be simply calling the function directly.) Perhaps module_invoke_api or module_call_function would be in order. As Drupal evolves, more and more modules will provide an API available for use by other modules. In fact, there are already several such modules, such as getID3, Voting API, and others, which do nothing but provide glue for other modules to work with. We need to encourage this cooperation, and if not provide an easy and safe method for invoking a function in an API, at least document a best practice. Earnie Boyd wrote:
Quoting Chris Johnson <cxjohnson@gmail.com>:
module_invoke() is used to call core API functions in a special core API class called hooks. If your function is not part of the core API, then using module_invoke to call it is misleading. Misleading code is a maintenance problem. Some day, the functionality of module_invoke() may change and not work correctly to call random contributed module functions. It will always work to call hooks, however. Hence, by definition, it is wrong to use it for a purpose it was not meant.
Correct, and stating it like Chris has said we can go as far to say that module_invoke is a private core function reserved for the use of the hooks class. Modules themselves should not use it unless the module has created a hook and needs to call other modules implementations of that hook.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Aaron Winborn <winborn@advomatic.com>:
at least document a best practice.
mymod.info dependencies = urmod mymod.module $mymod_bar = urmod_foo(); Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Doesn't work in many cases. I frequently build modules with optional dependencies. Even with your set up, we're assuming a module's api stays the same within a core version, which is frequently not true. There's no easy answer for the first case, other than bloating your code with additional drupal_function_exists checks, and the second would require tracking module version (at least its major version). Earnie Boyd wrote:
Quoting Aaron Winborn <winborn@advomatic.com>:
at least document a best practice.
mymod.info dependencies = urmod
mymod.module $mymod_bar = urmod_foo();
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
How about: mymod.info dependencies[] = taxonomy, someothermod 1.x, urmod optional_dependencies[] = optionalmod 2.x mymod.module $mymod_bar = module_call('optionalmod', 'cool_function', $args); if (isset($mymod_bar)) { $mymod_foo = module_invoke('urmod', 'some_hook', $mymod_bar); } Aaron Winborn wrote:
Doesn't work in many cases. I frequently build modules with optional dependencies. Even with your set up, we're assuming a module's api stays the same within a core version, which is frequently not true.
There's no easy answer for the first case, other than bloating your code with additional drupal_function_exists checks, and the second would require tracking module version (at least its major version).
Earnie Boyd wrote:
Quoting Aaron Winborn <winborn@advomatic.com>:
at least document a best practice.
mymod.info dependencies = urmod
mymod.module $mymod_bar = urmod_foo();
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Wed, Jun 25, 2008 at 6:14 PM, Aaron Winborn <winborn@advomatic.com> wrote:
mymod.module $mymod_bar = module_call('optionalmod', 'cool_function', $args); if (isset($mymod_bar)) { $mymod_foo = module_invoke('urmod', 'some_hook', $mymod_bar); }
Again, I do not see the point of module_call if you can do: if (drupal_function_exists('cool_function')) { $mymod_bar = cool_function($args); } Advantages? - It is cleaner and faster - It does not add a new level of indirection - It makes reference tracking works (such as what is done on api.drupal.org) Moreover, you can do correct error management: if (drupal_function_exists()) { } else { } Damien
On 25 Jun 2008, at 6:01 PM, Aaron Winborn wrote:
There's no easy answer for the first case, other than bloating your code with additional drupal_function_exists checks, and the second would require tracking module version (at least its major version).
we need this anyway. badly.
Quoting Adrian Rossouw <adrian@bryght.com>:
On 25 Jun 2008, at 6:01 PM, Aaron Winborn wrote:
There's no easy answer for the first case, other than bloating your code with additional drupal_function_exists checks, and the second would require tracking module version (at least its major version).
we need this anyway.
Now this I agree with. But we could development a MOP to handle this easily enough. Something like define('MYMOD_VERSION', '2.x') but be good enough for that.
badly.
The other option is to read the module.info file and grab the version info from it. The version info is appended to the file by the packaging script and could be easily parsed using the PHP function parse_ini_file; like $urmod_info = parse_ini_file('/path/to/urmod/urmod.info'). Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On 25 Jun 2008, at 8:58 PM, Earnie Boyd wrote:
Now this I agree with. But we could development a MOP to handle this easily enough. Something like define('MYMOD_VERSION', '2.x') but be good enough for that.
http://php.net/version_compare i actually think we need something a bit more severe, tho it's probably out of spec for D7. ie : versioned content types (from cck) and views. so you can have a module require a specific version of a view.
Adrian and Earnie wrote:
There's no easy answer for the first case, other than bloating your code with additional drupal_function_exists checks, and the second would require tracking module version (at least its major version).
we need this anyway
badly.
The other option is to read the module.info file and grab the version info from it.
There's already a patch for this here, crying out for some attention : http://drupal.org/node/211747
On Wed, Jun 25, 2008 at 1:06 PM, Adrian Rossouw <adrian@bryght.com> wrote:
On 25 Jun 2008, at 6:01 PM, Aaron Winborn wrote:
There's no easy answer for the first case, other than bloating your code with additional drupal_function_exists checks, and the second would require tracking module version (at least its major version).
we need this anyway.
badly.
drupal_function_exists or module version tracking? I know it would be great to have it centralized, but currently requirement checking can be done in hook_requirements.. although it would be nice to have some automagic in .info for it.
Reading this thread, i ask myself and you why not using a established package format like RPM http://en.wikipedia.org/wiki/RPM_Package_Manager , deb-format or some other out of the linux - environment, compared on http://kitenet.net/~joey/pkg-comp/ Or if you are afraid of high complexity and efford to support such a format on all plattforms - then give the PEAR-or PECL-format a chance. I don't want to say any of these formats meets the requirements, but i did not have seen this formats discussed. What do you think about an more generaly used format for Drupal-packages? Best Thomas Zahreddin Krüzastr. 18/15 A-6912 Hörbranz T. +49 89 420951948 o. +43 5573 83048 F. +49 89 420951948-9 mailto:tz@it-arts.org
Quoting Thomas Zahreddin <tz@it-arts.org>:
Reading this thread, i ask myself and you why not using a established package format like RPM http://en.wikipedia.org/wiki/RPM_Package_Manager , deb-format or some other out of the linux - environment, compared on http://kitenet.net/~joey/pkg-comp/
Or if you are afraid of high complexity and efford to support such a format on all plattforms - then give the PEAR-or PECL-format a chance. I don't want to say any of these formats meets the requirements, but i did not have seen this formats discussed.
What do you think about an more generaly used format for Drupal-packages?
http://drupal.org/project/Installation+profiles But that doesn't help the need of module version dependency checking within the coded module. For that I've just uploaded Module Versions[1] to CVS. I've attached it to D5 for now. I'll get a D6 tag going tomorrow. The module should work for either and is aimed at Development and Developers only. [1] http://drupal.org/project/modver Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Darrel O'Pry <darrel.opry@gmail.com>:
On Wed, Jun 25, 2008 at 1:06 PM, Adrian Rossouw <adrian@bryght.com> wrote:
On 25 Jun 2008, at 6:01 PM, Aaron Winborn wrote:
There's no easy answer for the first case, other than bloating your code with additional drupal_function_exists checks, and the second would require tracking module version (at least its major version).
we need this anyway.
badly.
drupal_function_exists or module version tracking? I know it would be great to have it centralized, but currently requirement checking can be done in hook_requirements.. although it would be nice to have some automagic in .info for it.
Ooo, cool deal. With the Module Versions module[1] I just created you could write a hook for the requirement which is then displayed on the status page. [1] http://drupal.org/project/modver Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Michael Prasuhn <mike@mikeyp.net>:
On Jun 24, 2008, at 10:48 AM, Earnie Boyd wrote:
Quoting Frando <frando2@unbiskant.org>:
In Drupal 7, module_invoke uses module_hook uses drupal_function_exists. I don't see why you should not use module_invoke to call API functions.
As I have already stated it isn't the defined use of the function. The defined use of the function is to execute hook implementations. If it is used for anything else then confusion will happen and perhaps cause for a lot of frustration in maintenance.
I don't buy it. This looks like an excellent use of an existing function that does exactly what is called for. What defines a 'hook' anyway? Is a function not a hook if only one module implements it? Would it be such a stretch to think of every function as a hook to be invoked in multiple different ways?
http://api.drupal.org/api/group/hooks/7 Yes it is a bit of a stretch to think of every function as a hook because every function isn't supposed to be and doing so causes confusion and hardship in maintenance. The definition of module_invoke is to invoke implemented hooks and shouldn't be used as a lazy method of calling a function. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Daniel F. Kudwien wrote:
Also, module_invoke() is not limited to Drupal hooks / API callbacks. If the returned results of call_user_func_array() work for your particular implementation, this is the best approach for each module that wants to integrate with another, optionally installed module in contrib. Assuming you dont want to do something else if the module/function doesn't exist of course. Which in my usage is normally the case. I suppose checking the boolean return value from call_user_func_array() would probably suffice for most cases unless FALSE is a valid return from the function that didn't exist in the first place. Tricky, tricky. Who's on first? -- Michael Favia michael@favias.org tel. 512.585.5650 http://www.favias.org
As we don't have public and private scope, I think that in practice, failing a better method, module_invoke should be the safer way to do this. In my modules, if I have functionality I don't want to expose, I prefix it with an underscore: _module_name_private_api. 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. Additionally, module_invoke would allow for optional dependence, which is generally where I use that anyway. ----- Original Message ----- From: "Earnie Boyd" <earnie@users.sourceforge.net> To: development@drupal.org Sent: Monday, June 23, 2008 8:20:29 AM GMT -05:00 US/Canada Eastern Subject: Re: [development] module_exists vs. functions_exists? Quoting Aaron Winborn <winborn@advomatic.com>:
I usually use the following pattern:
if (module_exists('module_name')) { $foo = module_invoke('module_name', 'api_function', $bar); }
I think you're correct in using this; but only for hooks. You've stated 'api_function' when it is actually the 'hook'. And if mymodule_myfunction isn't a hook should we be using module_invoke to do the call? No, we should call the function directly. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Aaron Winborn <winborn@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/
participants (19)
-
Aaron Winborn -
Adrian Rossouw -
Chris Johnson -
Damien -
Daniel F. Kudwien -
Darrel O'Pry -
Darth Clue -
Earnie Boyd -
Frando -
Greg Knaddison - GVS -
Juan Rodriguez -
Khalid Baheyeldin -
Larry Garfield -
Michael Favia -
Michael Prasuhn -
Moshe Weitzman -
Nancy Wichmann -
Nathaniel Catchpole -
Thomas Zahreddin