module names and namespaces
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
David This is the reason I've always been very against using db_query("DELETE FROM {variable} WHERE name LIKE 'modulename_%'"); in a module's hook_uninstall. I always use variable_del() on each variable itself. It's how core handles itself, so in my opinion that's how contrib should follow. Dave Reid dave@davereid.net On Sat, Oct 16, 2010 at 11:34 AM, David Cohen <drupal@dave-cohen.com> 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
If you want a concrete example, both fb.module and fb_social.module define variables starting with "fb_"
The fb_social module is therefore violating namespace rules. It may only use names within the "fb_social" namespace, but not "fb". There are more complex namespace problems with module names and hooks, but this case sounds like the easy case. sun
But isn't the entire "fb_social" namespace within the "fb" namespace? On Saturday 16 October 2010 09:54:09 Daniel F. Kudwien wrote:
The fb_social module is therefore violating namespace rules. It may only use names within the "fb_social" namespace, but not "fb".
There are more complex namespace problems with module names and hooks, but this case sounds like the easy case.
sun
But isn't the entire "fb_social" namespace within the "fb" namespace?
Yes, but that's the edge-case for which no solution exists. There are various node_* or views_* or user_* modules, which all have to make sure that none of them unintentionally breaks the functionality of the "parent" namespace. That said, "fb_social" is only able to break the "fb" namespace in case "fb" implements stuff that starts with "fb_social". Sounds rather unlikely to me, but I also don't know your code. In any case, this namespace conflict sounds easily resolvable through a gentle agreement of both maintainers. sun
Yeah, don't get me wrong. I'm not _trying_ to break fb_social or any other module. But I did by accident. :) And I might break future fb_... modules if I don't know they exist. Within modules/fb/ there are a number of modules named fb_something, and I'll create new ones as needed. -Dave On Saturday 16 October 2010 14:05:18 Daniel F. Kudwien wrote:
But isn't the entire "fb_social" namespace within the "fb" namespace?
Yes, but that's the edge-case for which no solution exists. There are various node_* or views_* or user_* modules, which all have to make sure that none of them unintentionally breaks the functionality of the "parent" namespace.
That said, "fb_social" is only able to break the "fb" namespace in case "fb" implements stuff that starts with "fb_social". Sounds rather unlikely to me, but I also don't know your code.
In any case, this namespace conflict sounds easily resolvable through a gentle agreement of both maintainers.
sun
On Sat, Oct 16, 2010 at 3:19 PM, Dave Cohen <drupal@dave-cohen.com> wrote:
Yeah, don't get me wrong. I'm not _trying_ to break fb_social or any other module. But I did by accident. :)
And I might break future fb_... modules if I don't know they exist. Within modules/fb/ there are a number of modules named fb_something, and I'll create new ones as needed.
-Dave
As an off-the-cuff suggestion, you could start renaming things fb_core_... instead of fb_..., and make it very clear to folks that fb_core is being adopted as the namespace for the module. That way the only way you'll step on someone is if they create an fb_core module, which would be foolhardy if they already know about the fb module and how it works. -- John Fiala www.jcfiala.net
Hi, Where the real problem comes in is in projects which have multiple modules. generally when you have a single module the name of the project and module at the same, but when you have more and one module such as fb_social you start using "unregistered" namespaces. Gordon. On 17/10/2010, at 7:33 AM, Dave Cohen wrote:
But isn't the entire "fb_social" namespace within the "fb" namespace?
On Saturday 16 October 2010 09:54:09 Daniel F. Kudwien wrote:
The fb_social module is therefore violating namespace rules. It may only use names within the "fb_social" namespace, but not "fb".
There are more complex namespace problems with module names and hooks, but this case sounds like the easy case.
sun
This is a well-known problem that comes up less often than most fear, but does come up. :-) In this case, it sounds like fb_social is Doing It Wrong(tm). There's been periodic talk of changing the way hooks work to avoid this problem, although that would not help with variables. The leading contenders for hooks are to switch to _hook_ as a separator rather than just _, or to use PHP 5.3 namespaces. There are open issues for both targeted at Drupal 8. Personally I lean toward the namespaces approach but it's still too early to know what we're going to do there, as there are a LOT of issues to consider. On Saturday, October 16, 2010 11:34:05 am 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
The function names the first thing we think of, but there are other places where the module name implies a sort of "namespace". Variables we've mentioned, also database tables, data in the database like the authmap.module column, drupal_render data structures like $form['foo_data'], and so on... I don't think php namespaces or another separator are enough to prevent the problem. But simply not using '_' in a module name would. And I say this as someone who has used '_' in module names in the past (i.e. tac_lite). Now I understand the problem, so I won't do that again. -Dave On Saturday 16 October 2010 10:29:58 Larry Garfield wrote:
This is a well-known problem that comes up less often than most fear, but does come up. :-) In this case, it sounds like fb_social is Doing It Wrong(tm).
There's been periodic talk of changing the way hooks work to avoid this problem, although that would not help with variables. The leading contenders for hooks are to switch to _hook_ as a separator rather than just _, or to use PHP 5.3 namespaces. There are open issues for both targeted at Drupal 8. Personally I lean toward the namespaces approach but it's still too early to know what we're going to do there, as there are a LOT of issues to consider.
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/
Hi, Just wanted to contribute with a different point of view. Regarding the original problem, it's my opinion that fb_social did nothing wrong, it's your fault for assuming that you own the fb prefix and deleting every variable starting with that prefix. You should delete what you know that you own. So I second Dave Reid's opinion and suggest that you do a grep of variable_?et in your code and convert the results into variable_del calls. However, there is indeed a problem here. I maintain the print module, to which I have added two sub-modules (print_mail and print_pdf).. Should I register those projects in drupal.org so that no one takes those names away (since the module is used by >35K sites, it would have to be done by someone with bad intentions and manners, but this is just an example). In the *_uninstall() of each of those modules, there a LONG list of variable_del calls. The problem is that I also create some per-content-type variables which are named print_display_[content type name], and it's simply not possible to know which content types existed at any time between installing the module and uninstalling it, that are no longer present. As such, the only solution is to delete everything starting with [module name]_display. Should I also register the print_display, print_pdf_display and print_mail_display projects? I think that the best solution would indeed be to create a new coding standard where the variables created by each module would be prefixed with the module name followed by a double (or triple?) underscore.. In my case, all variables with either be print__*, print__mail_* and print__pdf_*. One could even consider that I should rename the modules to print__pdf and print__mail, according to that coding standard. And drupal.org would have to be modified to prevent creating project names with double underscores of course, or this problem would resurface one of these days.. I think it is important to decide what to do with this in order to prevent problems in the community over such an irrelevant thing. João
On Thursday, October 21, 2010 5:26:23 am João Ventura wrote:
Hi,
Just wanted to contribute with a different point of view. Regarding the original problem, it's my opinion that fb_social did nothing wrong, it's your fault for assuming that you own the fb prefix and deleting every variable starting with that prefix. You should delete what you know that you own. So I second Dave Reid's opinion and suggest that you do a grep of variable_?et in your code and convert the results into variable_del calls.
However, there is indeed a problem here. I maintain the print module, to which I have added two sub-modules (print_mail and print_pdf).. Should I register those projects in drupal.org so that no one takes those names away (since the module is used by >35K sites, it would have to be done by someone with bad intentions and manners, but this is just an example). In the *_uninstall() of each of those modules, there a LONG list of variable_del calls.
That's what this discussion is for: http://drupal.org/node/145164
The problem is that I also create some per-content-type variables which are named print_display_[content type name], and it's simply not possible to know which content types existed at any time between installing the module and uninstalling it, that are no longer present. As such, the only solution is to delete everything starting with [module name]_display. Should I also register the print_display, print_pdf_display and print_mail_display projects?
That's what this API hook is for: http://api.drupal.org/api/function/hook_node_type/6 At least some parts of the issue have very straightforward technical solutions that either already exist or are already under discussion. --Larry Garfield
participants (9)
-
Aaron Winborn -
Daniel F. Kudwien -
Dave Cohen -
Dave Reid -
David Cohen
-
Gordon Heydon -
John Fiala -
João Ventura -
Larry Garfield