On CPAN Namespaces: Urban Namespace Planning

I’m having a bit of a conundrum over where to put my next GSL-based module. First some background.

I’m already the author of a GSL-based module (see my first rant), the horribly named Math::GSLx::ODEIV2. This name reflects the same odd namespacing conundrum that I find myself in again, as well as the sub-library name odeiv2.c/h.

Duke Leto has already essentially taken the whole Math::GSL namespace by brute-force SWIG-ing the entire library. Much of this work is not fully implemented, but still parked. Further, since the namespace is already fairly crowded, its next to impossible to tell which parts are his and which would be anyone else’s. So lets call that out of the running. Note that I’m not complaining about his efforts, but it makes choosing a name harder.

I released my first module which uses GSL under the namespace Math::GSLx, but this is also less than desirable since it seems to be related to Math::GSL which it isn’t (at least not in the way that MooseX is related to Moose). Its also hard to type and hard to search for.

This leave me thinking about starting a new toplevel, which I do not undertake lightly. My two concepts are the simple GSL and the more namey PerlGSL. I say namey since toplevels with names like Mojolicious are not contentious since they represent more of a concept than an implementation detail (like Net::).

To be distinct from Math::GSL I would encourage users of PerlGSL to

  1. Make their interfaces Perlish rather than the utilitarian output the SWIG may produce
  2. Give their module a name that is descriptive without squatting on the sub-library name or other implemenations

In this way if two different authors want to provide an interface to GSL’s Monte Carlo multidimensional integrator, one might be PerlGSL::Integration::MultiDim (since there are a number of 1D integrators to be considered) and another might be PerlGSL::Integration::NDim.

Once I settle on a toplevel, I expect that I will “release” a namespace decriptor module (not unlike Alien) describing this for future users. It might also eventually pull in the GSL library via Alien::GSL once my Alien::Base work permits. From there I would release PerlGSL::Integration::MultiDim and rechristen Math::GSLx::ODEIV2 as PerlGSL::DiffEq (assuming the toplevel PerlGSL).

Anyway, I’m interested in your comments, so please let me know!


Although there is a top-level Perl:: namespace, it’s used for modules related to the Perl language or code, such as Perl::Critic and Perl::Tidy. Some modules use ::Perlish to designate a Perlish syntax or semantics, but it doesn’t sound like an option here. PerlIO comes to mind as an existing module that starts with Perl, but PerlGSL doesn’t sit right with me. I agree that naming is difficult in this situation. Ideally multiple GSL-related modules would live under Math::GSL::.

If each distribution is going to wrap a specific functionality, then you might be better off with something like Math::MonteCarlo::GSL? I seem to recall seeing similar naming schemes used, though I can’t think of an example right now. And I agree that PerlGSL just sounds wrong.

I would use Maths::GSL.

If I’ve got ODE’s to solve, my primary concern is getting an ODE solver, and the underlying numerical library is a secondary worry. This is doubly true if I don’t have to worry about installation of the numlibs (yay Alien!). Therefore, I think you should call it Math::ODESolver, or maybe Math::ODESolver::GSL if you want to be on an equal footing (in terms of namespace depth) with any other future implementations.

@Ben, Maths::GSL is not much better than Math::GSLx.

Is it really not possible to use anything under Math::GSL::? I’m not sure I understand why - there are a lot of modules in that Leto package but does it actually consume the whole namespace?

Anyway, I agree with TNish’s comment that the user problem to be solved is the best place to put the module.

Given the size (read: number of modules) of Math::GSL, I consider this like the unified modules Mojolicious or Moose. You wouldn’t add to those namespaces would you?

I wouldn’t add to the Mojolicious or Moose namespace because Mojolicious and Moose are “products” of the developers and the “funny namespace” reflects that. If I added my module to that “funny namespace” it would be like I was pretending my module was part of the product.

But I’m quite happy to add to “WWW::” or “Data::” namespaces which probably have more modules than “Moose::*”. I don’t see why Math::GSL::MyModule is going to upset the applecart.

I was so interested that I counted them:

$ grep -c "^Moose::" 02packages.details.txt 
$ grep -c "^WWW::" 02packages.details.txt 
$ grep -c "^Data::" 02packages.details.txt 
$ grep -c "^Mojolicious::" 02packages.details.txt 
$ grep -c "^Math::" 02packages.details.txt 
$ grep -c "^Math::GSL" 02packages.details.txt  

I have never used Math::GSL, but know enough about SWIG* to know that writing good Perl modules using it is almost impossible.

So, IMO, the GSL namespace should be untouched just in case somebody volunteers to make a full wrapper of GSL using XS.

For your particular case I would probably go for Math::ODE::GSL.

* enough because I did a full rewrite of the SWIG Perl backend once

In my experience, SWIG is more trouble than it’s worth for just wrapping a C library for Perl. But if you want to wrap it for users of multiple scripting languages, it can be worth the trouble. e.g. I wrapped an “O-O C” library as O-O Perl, Python, Ruby, and Java using a single interface definition, and it actually turned out okay in all 4 languages. Really, single-inheritance O-O is the same glop everywhere.

Leave a comment

About Joel Berger

user-pic As I delve into the deeper Perl magic I like to share what I can.