With several modules I collaborate on, such as Media, Media: YouTube, Node Reference / Embed Media Browser (nrembrowser), etc, we are using a customized version of the proposed variable API that didn't make it into d7: http://drupalcode.org/viewvc/drupal/contributions/modules/media/includes/med... Prepends all variables with media__ (note the double underscore). Also, by defining all definitions, allows for an easy uninstall, with: foreach (media_variable_default() as $name => $value { media_variable_del($name); } This allows modules to use similar namespacing (as the problem is not simply going to go away). Also defines variable defaults, so that vars are called like: media_variable_get('file_extensions'); which is easier to deal with on many levels than variable_get('media__file_extensions', 'jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp mp3 mov m4v mp4 mpeg avi ogg wmv ico'); and can also be overridden as usual with media_variable_get('file_extensions', 'jpg jpeg gif png'); For updating modules from an old scheme to the new scheme, look at http://drupalcode.org/viewvc/drupal/contributions/modules/media_brightcove/m... /** * Convert variables to the Media: Brightcove variable namespace. */ function media_brightcove_update_6102() { $ret = array(); $variables = array( 'brightcove_publisher_id' => 'publisher_id', 'brightcove_player_id' => 'full_player_id', 'brightcove_player_preview' => 'preview_player_id', 'emvideo_brightcove_token' => 'read_token', 'emvideo_brightcove_write_token' => 'write_token', ); foreach ($variables as $old_variable => $new_variable) { _media_brightcove_migrate_variable($old_variable, $new_variable); } $ret[] = array('success' => TRUE, 'query' => "Converted variables to the Media: Brightcove variable namespace."); // Add the new settings page to the menu. menu_rebuild(); $ret[] = array('success' => TRUE, 'query' => "Rebuilt the menu for the new administrative settings page."); return $ret; } /** * Migrate a variable from the old namespace. */ function _media_brightcove_migrate_variable($old_variable, $new_variable) { $value = variable_get($old_variable, media_brightcove_variable_default($new_variable)); if (media_brightcove_variable_get($new_variable) != $value) { media_brightcove_variable_set($new_variable, $value); } variable_del($old_variable); } On 10/16/2010 12:34 PM, David Cohen wrote:
Hey, I'm wondering what the community thinks about this...
I feel that if I have modules/foo/foo.module checked into drupal.org CVS and drupal.org/project/foo, then this module stakes a claim to the foo_... namespace. That is, I can name my functions foo_whatever without worrying that some other module out there already defines the same function. Similarly, I can name my variables foo_whatever, database tables, and so on.
Now, let's say someone else checks in a module called foo_bar. And say both modules define the same function, variable or other namespace collision. What then? Is that a bug, and if so which module is responsible for fixing it?
If you want a concrete example, both fb.module and fb_social.module define variables starting with "fb_", and specifically I wonder how to respond to http://drupal.org/node/943462.
I don't want to start a flame war. I'm curious if there is community consensus or official policy. Personally I think its a bad idea to name any module with an underscore. That is, drupal.org/project/foo_bar should instead be drupal.org/project/foobar, as this avoids any confusion.
-Dave
-- Aaron Winborn Advomatic, LLC http://advomatic.com/ Drupal Multimedia available in September! http://www.packtpub.com/create-multimedia-website-with-drupal/book My blog: http://aaronwinborn.com/