Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

masak (6289)

  (email not shown publicly)

Been programming Perl since 2001. Found Perl 6 somewhere around 2004, and fell in love. Now developing November (a Perl 6 wiki), Druid (a Perl 6 board game), pls (a Perl 6 project installer), GGE (a regex engine), and Yapsi (a Perl 6 implementation). Heavy user of and irregular committer to Rakudo.

Journal of masak (6289)

Friday December 11, 2009
11:29 AM

Some module names don't deserve to be short

[ #40008 ]

carlin++ is doing some much-appreciated testing of the installed-modules branch of proto. He's now at the point where he's hunting down module name conflicts across projects.

Why are we interested in conflicts? Because the job of the installed-modules branch is to install Perl 6 modules into a common modules directory, and then module name collisions suddenly become a reality.

Some collisions were due to modules both resting in the perl6-examples repo, and having moved out of it to separate repositories. Those were the easy ones to take care of. Nice to be rid of duplicates, too.

carlin dug up one collision that surprised me. There was a Tags module in November, and a Tags module in This never occurred to me before, despite the fact that I've witnessed the creation of both. The module in November handles the subject tagging of article pages in the wiki, as well as tag clouds (ihrd++). The module in helps serialize HTML tags (Tene++). So this is not an easy case where one of the modules is a stale copy; they're actually non-homologous.

Yet the solution was clear after only a moment's thought: Tags in the repo had the right to the short name (for now, at least), whereas Tags in November should really be November::Tags. I fixed that, and carlin could move on, unblocked.

Then I had a look at November, as if with new eyes. There are lots of modules there which really don't deserve such short names. Not in a connected world, that is, where a project suddenly needs to take other projects into account, and not just clobber namespaces willy-nilly.

These were the ones I decided to prefix with November::: CGI, Cache, Config, Session, Tags, Utils. Most of them because they simply are November-specific, so it makes more-than-sense to shove them into a November:: namespace, for clarity as well as for civility.

The exception is CGI, which could actually be in its own repo and used by other projects. I chose to shove that into the November:: namespace as a sort of social marker: November::CGI is our mess, we're getting rid of it as soon as we can, and we'd rather other people didn't use it.

Use instead. ☺

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I can't think of a single good reason to have a global namespace taken up with something like Tags. If a module produces XML or HTML tags, then name it XML::Tags or HTML::Tags. Otherwise it could be topical Tags (like it seems november was trying to do), or price tags, or freeze tags, or any number of thing.