[PBP-pm] Reviewing PBP recommended modules?

Matthew Simon Cavalletto simonm at cavalletto.org
Tue Nov 22 09:54:11 PST 2005


On Nov 22, 2005, at 12:42 PM, C. Garrett Goebel wrote:

>> At 11/22/2005 09:39 AM, Simon wrote:
>>
>>> I would urge you to consider posting these modules into the
>>> namespaces that make sense based on what the modules do, rather than
>>> grouping them together based on an aspect of their implementation.
>
> One of the reasons I'd like to see a PBP:: namespace is that assuming
> functional requirements have been met, I would prefer to use modules
> which consistently apply the same documentation, style, idiom,  
> testing...
> in short, everything that constitutes coding practices.

Agreed.

> CPAN being what it is... how do you suggest someone find modules which
> bill themselves as PBP conformant?

Searching for PBP is easy enough:

   http://search.cpan.org/search?m=all&n=100&q=pbp

> Which would you prefer:
> o  Getopt::CmdLine::PBP?
> o  PBP::Getopt::CmdLine
>
> The first leaves the module name mostly intact, but forces it into  
> someone
> else's namespace while scattering the PBP designation to the four  
> winds.
>
> The last allows all the PBP modules to be found from one starting
> point, and otherwise leaves the module name intact.

I'd prefer the first, and the existing PBP-style equivalents already  
published to CPAN seem to use this approach: Module::Starter::PBP and  
ExtUtils::ModuleMaker::PBP.

Existing CPAN convention seems to suggest that if you are creating a  
new-but-different equivalent of a module named X, it should be called  
X::Foo. (For example, a pure-Perl implementation of an XS module is  
often named X::PurePerl.)

Having a bunch of modules named Foo::X and Foo::Y tends to suggest  
that they're part of a framework, and specifically intended for use  
within that framework. (For example, people have made smaller  
versions of Class::MethodMaker that only include the features they  
need, named Foo::MethodMaker.)

> I don't expect many CPAN maintainers to be interested in applying
> internals-only patches to bring their modules into line with PBP
> recommendations. Perhaps I'll be surprised.

Maybe... Certainly there are a lot of random throw-away modules which  
aren't really maintained and for which patches are more likely to be  
ignored, but I suspect that the authors of the more popular modules  
are likely to be more open to documentation and code style patches.

-Simon


More information about the PBP-pm mailing list