[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