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
- Make their interfaces Perlish rather than the utilitarian output the SWIG may produce
- 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!
As I delve into the deeper Perl magic I like to share what I can.
Although there is a top-level
Perl::namespace, it’s used for modules related to the Perl language or code, such asPerl::CriticandPerl::Tidy. Some modules use::Perlishto designate a Perlish syntax or semantics, but it doesn’t sound like an option here.PerlIOcomes to mind as an existing module that starts withPerl, butPerlGSLdoesn’t sit right with me. I agree that naming is difficult in this situation. Ideally multiple GSL-related modules would live underMath::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.
@All, any comments on using
GSL::?@Nick, I wish I could use
Math::GSL, but as my modules will not be SWIG-based this is essentially unavailable to me, sadly. And yesPerlGSLseems odd.@chimerix, I do rather like the concept of
Math::MonteCarlo::GSL, but it has two problems, 1) Monte Carlo can mean more than integration, and more importantly 2) GSL is an external dependency which needs satisfying so I think tying many GSL dependent modules into one namespace is important.@Ben,
Maths::GSLis not much better thanMath::GSLx.:-/
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.
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? It is interesting to me that people seem to be coalescing around separating the GSL modules by function, I really hadn’t thought of that, I guess I will have to consider it.
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:
I’m confused, doesn’t that show my point? A similar number of modules, all made by one person for one purpose, by one mechanism (SWIG). I wish Leto HAD used a “funny namespace” like
Math::GSL::SWIG::, but this is where we find ourselves.Now if you were looking for a multidimensional integrator, and knew that Math::GSL used a SWIG interface which is often incomplete and not very Perlish, wouldn’t you pass on the mine without even looking at it? I would. It has nothing to do with balance, and more to do with being distinct from that project.
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
Indeed that was my reason for suggesting
PerlGSLto be more aGSL dist for Perl. However, now to play “Devil’s advocate”, is it likely that anyone is going to make a full wrapper of the GSL? Might it not be reasonable to suspect that, like me, authors might only wrap those functions that they need? I would love it if someone did make a full wrapper, however unlike other libraries, (saySDL) you almost never need all of the GSL.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.