Regrettable module names

[brian_d_foy]

For a while, years really, I have been musing about this thing I have wanted to write about naming modules. I get to think about this a lot because lately I've been the one approving (or not) most of the modules submitted to The Module List.

Aside from the usual naming advice I'm curious about how modules which we thought we had named well turned out not to have such great names. Surely that is always going to happen, but maybe there is something to learn there. A "regrettable" module name may have seemed really good at the time, others may have agreed with you, and maybe even I approved the name for the module list. Then time passed and things turned out differently. I don't want to call these "bad" names, or "sub-optimal" names, just "if-i-had-to-do-it-over" names.

Before I invite others to talk about their regrettable module names, I'll go through my own module list. After that, please feel free to tell me privately or in public about your regrettable names, and whether I get to use your stuff in a future article.

Now, on to it:

Business::ISBN

I think this was my first module, and if not, my second. Ed Summers now maintains it, and for a couple years he and Andy Lester mused about moving it to a Biblio::* namespace. At the time I uploaded it (1998ish), I wasn't really happy with the name, but there was nothing else like it on CPAN. Jon Orwant had Business::CreditCard, which was another checksumming module, and as I recall he suggested they might live together. Since then, Business::ISBN does a lot more than just checksum stuff (it handles xISBN, EANs, barcodes, and more), and it certainly is not just a business thing: I could use this module to catalog my personal library. Still , that's not how it turned out.

HTML::SimpleLinkExtor

Ughh. I certainly wish someone had slapped me around a bit when I suggested that name. HTML::LinkExtor::Simple would have been much better since it is just a subclass with a lit decoration. I now know the ugliness of putting too many things into the same namespace name level.

ConfigReader::Simple

This one isn't really my fault because I took over the module for some reason I forget: I might have been the sole user. This is the sort of module that everyone writes, like the GetOpt stuff. Just like HTML::SimpleLinkExtor, this one stuffs too much into a namespace level: Config and Reader. Now it writes too. Like Business::ISBN, this one grew out of its name. Better name: Config::Simple.

Test::Manifest

I wrote this to get back some functionality that modern versions of Test::Harness lost. I want to decide which tests and the order of tests to run, despite what's in the t directory. I use a file I call test_manifest, so Test::Manifest seemed to make sense. But, with its name, people sometimes think it has something to do with MANIFEST. Better name: no idea, Test::Order?

Netscape::Bookmarks

I wrote this shortly after Business::ISBN, and this one has two gotchas: Netscape is virtually dead, and it starts specific and goes to general. Company names make for poor namespace names, and product names, like Navigator, the actual product may be better. If I had been thinking about more of the world than just Navigator way back when I wrote this, i would have planned to handle bookmarks for other browsers too. I did this with the various HTTP::Cookies::* modules ( ::Mozilla, ::iCab, and so on), and I wish I had done something like WWW::Bookmarks::Navigator, ::iCab, and so on. Like the HTTP::Cookies::* modules, the WWW::Bookmarks::* could share a common internal format that makes it easy to convert between borwser formats. Naming from general to specific makes for easier expandibility.

So now that I've told you about some of mine, what about yours? Talk about other people's modules at your own risk.

[theorbtwo]

Here's one that I'm not sure of -- Sort::Merge. It implements the algorithim commonly called merge sorting. Unfornatly, it doesn't sort -- it takes multiple files, which are already sorted, and merges them info one file, that is sorted. But I'm stuck with the name, because it's what everybody calls the algo.

Another that I'm not sure of, that indicates a general problem, I think. I'm working on a interface to my bank's web-banking. It's called Finance::Bank::Norisbank (yeah, compony names don't make good namespaces, but there's really nothing better to call it, other then, perhaps, Finance::Bank::DE::Norisbank, or Finance::Bank::DE::<their bank routing number here>. The first is getting too long, the second is unreadable.

The real problem, though, is the class that is to be used to represent a transaction. By design, it's supposed to be general enough to represent any transaction, or at least any transaction against a german bank. Should I name it Finance::Bank::Transaction, Finance::Bank::DE::Transaction, or are those taking up valuable namespace for something that will probably only be used by me, and it should be Finance::Bank::Norisbank::Transaction?

(BTW, Finance::Bank::Norisbank is not ready for CPAN yet.)

[brian_d_foy]

That Finance::* namespace is a wierd one. It has general things like interfaces to various accounting programs data formats as well as protocol sorts of things. Lingua::* has a similar complexity.

To make things really work there, someone needs to take charge and unify everyone, sort of like DBI did for databases and LWP did for many of the net interfaces. What you really care about is the transaction, not the institution, really. If I wanted to interact with four banks (and I do), I want to use the same script.

That stuff aside, I think in your case you can't escape having the bank name in the module name, because that's how people think about it. If Citibank disappears, for instance, Finance::...::Citibank probably won't be useful anymore anyway, whereas in my example Netscape lived on in other things.

As a PAUSE admin, in these cases I just follow the precedent.

[davido]

This isn't my name, but it is nevertheless regrettable.

• Base: Not to be confused with base, but easily confused on operating systems that don't know how to deal with case-sensitive filenames. 'Base' really ought to just be removed from CPAN. From what I can tell it hasn't been maintained in ages, and is all but replaced by the 'base' pragma.
  

Often I find CPAN module functionality under module names that I wouldn't immediately have guessed, but as quickly as I stumble across such modules I forget my frustration and just go on using them. But the Base/base issue bugs me.

[TStanley]

Acme::Remote::Strangulation::Protocol

The idea for this module resulted from a conversation I had with chromatic here on Perl Monks, and was designed basically as a joke. The name I gave it is way to long, but I felt that naming it something like Acme::RSP wouldn't be very descriptive either.

[biosysadmin]

I like this one. The only thing that I think you could possibly do better would be to imply the Protocol somehow and just name it Acme::Remote::Strangulation. Also, some code examples in the perldoc would be nice too. :)

[TStanley]

Thank you for the suggestions :-) I will put them in my To-Do list for the module.

[ChemBoy]

Shouldn't it be Acme::Strangulation::Remote? Seems more in keeping with the general-to-specific idea of name spaces...

[hv]

To my mind, the biggest problem is uniqueness. How many different ways are there to design a "Foo::Simple" module? I'd suggest a name such as Config::Simple really doesn't tell anyone what they need to know, and rather only reflects who grabbed the name first.

As I understand it, perl6 will help solve this problem (or at least swap it for some new ones) by including the author as part of the significant namespace. That will free you up to release "Config::Reader" - to concentrate the name on what it does rather than how it does it.

Hugo

[brian_d_foy]

Indeed, "Simple" tends to not be so simple anyway as things get added to it. It's probably almost always wrong. :)

[DrHyde]

See also: *::Light (or Lite for those who can't speel)

[demerphq]

Naming things intelligently is hard. It requires a certain genius that frankly I think most people, like myself, lack. I spent a long time agonizing over what to call Data::Dump::Streamer. I eventually went with that name over some strong internal reservations (its too damn long for a utility modules) because a number of folks who i respect quite a bit seemed to favour it. Although a few releases later I added a "psuedo-namespace" to it called DDS, its not listed or registed but can be optionally installed when building DDS. The problem was that most of the Data:: namespace'es useful names are already taken, with a bunch of them taken by fairly poor quality modules. In fact I need to remove Data::BFDump as being obsoleted by Data::Dump::Streamer.

Also I've never understood why that name wasnt registered. Actually, while im not certain of this I have heard that of late very little registration is actually occuring. Perhaps because as you say you represent a SPOF and when you dont have the time the whole process comes to a halt.

The other one that _really_ annoys me is that the vast majority of Tie:: modules are horribly named. They should ALL be named Tie::Type(::Name)+. It seems so silly that there is no easy way to find out what types of tied array you can download for instance. I personally think Tie::Array::PackedC is a much better name than most of the Tie:: namespace. Consider:

Read more... (4 kB)

Pretty much none of that last part of the list should have been registered IMO. I suppose its arguable that the ones _ending_ in 'Type' should be in the "not so badly named", but IMO they are just as bad. And there are probably a few in there that cant be better named because they have some special extra property, but even still I think the namespace is a just a big mess.

[tilly]

And here we see why broadly-offered criticism is risky.

Take a look at Tie::Static which is one of your "outright badly named" modules. But take a closer look at it and tell me the better name that it should have, noting carefully that it handles scalars, arrays and hashes.

[demerphq]

And here we see why broadly-offered criticism is risky.

On the contrary I specifically mentioned that there would be a few such modules included in the "bad list":

And there are probably a few in there that cant be better named because they have some special extra property, but even still I think the namespace is a just a big mess.

So I think I preemptively resolved this point. Anyway, IMO that module should be named Tie::Any::Static or something along those lines. In fact, in my eyes the fact you cant tell that module can handle any type of tie just by looking at the name says to me its badly named.

[tilly]

Talk about other people's modules at your own risk.

I'll risk it.

My complaint is about Class::Null. First of all it might help if the documentation clarified what the Null Class design pattern is supposed to be. Unfortunately it doesn't turn out to be that there is a Null object on which you can make any method call and get another Null back. (You can use overload to make your Null act like undef where appropriate.) Allowing you to chain method calls together. This is what I would have hoped for.

I can think of at least 3 perlmonks saints who have independently written what I would like Class::Null to be. I would happily write a version for release, but I don't have any decent name to give it, the obvious one already being taken. :-(

So, there is one useful CPAN module which is waiting on a decent name before it can be written. Any suggestions?

[brian_d_foy]

I don't think that Class::Null is really the Null design pattern, despite what it says. The pattern is for a stand-in collaborator who doesn't do anything, not something you add to a module to handle calls to undefined methods. Your module shouldn't ever have to know it is using a null object.

[tilly]

I'd agree but I hate arguing over terminology. If someone cares enough about design patterns to have an opinion on what pattern they're using, I'm unlikely care enough to correct them. (I'm not a big fan of the design patterns movement. Shoot me.)

[QM]

I suppose Class::Null::Actually_Useful would be too facetious?

[tye]

So you are complaining rather than proposing a tiny patch (to the tiny module) to replace sub{} with sub{$_[0]} ?

[tilly]

Perhaps you mentioned the reference to overload? The needed changes to make the module do what I want are much bigger than what you said.

Which wouldn't be a problem except that the changes also have the disadvantage of not being backwards compatible with the current module. (For instance the returned objects should be false rather than true, which could mess someone up who tests that an object is there by checking for truth.) That incompatibility is why I decided to not offer a patch.

[beppu]

This one's not my own, but (sorry Schwern):

Ima::DBI

It's a subclass of DBI that gives it a few extra methods, and it's widely deployed now thanks to the popularity of Class::DBI.

Hello, I'm a DBI.

[BrowserUk]

Totally agree. Should have been I'm::a::DBI :)

[edan]

Quite right, since "Ima" means "Mother" in Hebrew (well, okay, Aramaic, but let's not get carried away), and I don't think it's supposed to be the mother of all DBI modules...

[hardburn]

That'll work great until you use some syntax-highlighting editor that mistakes it for a quoted string :)

You++ anyway, for finding an almost-good use of the single-quote package seperator.

[Matts]

It's not my module, but I'm now the maintainer. I'd complain about XML::Parser.

It's such a bad name because it assumes it is THE parser for XML, and it's just not. So people download it thinking it's the best interface to parsing XML in perl, and it's not.

[TimToady]

Well, yes, that one's basically my fault. The intent was that XML::Parser be an experimental workbench that could be extended into any kind of parser you like, but that didn't work out very well in practice. Oh well...

Still, it was the best at the time, if only because it was the first expat-based parser.

[grinder]

With all due respect to matija for a great module (which is in use here as I speak), File::Tail isn't the best name for what it does (implementing Unix's tail -f (follow) idiom). I've needed the real tail (last n lines of a file) in the past, and the best I found was to use File::ReadFileBackwards and read the n lines needed and reverse the resulting array. I would say that File::Tail::Follow would have been a better name. That would leave File::Tail available for the standard Unix tail idiom.

Another poorly-named module, one of my workhorses, is Mail::Sendmail, which sends mail. It does not, however, require the sendmail program to do its job.

[hardburn]

Another poorly-named module, one of my workhorses, is Mail::Sendmail, which sends mail. It does not, however, require the sendmail program to do its job.

For that matter, Sendmail itself is a regrettable name. It probably made sense at the time, but is no longer the way to send mail.

[gellyfish]

I think you might find that there are some people who disagree with you

/J\