[development] module names and namespaces

[João Ventura]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20101021/9ed7ce15/attachment.html