[PBP-pm] Reviewing PBP recommended modules?

C. Garrett Goebel ggoebel at goebel.ws
Tue Nov 22 09:42:45 PST 2005


On Tue, 22 Nov 2005, Rob Biedenharn wrote:
> At 11/22/2005 09:39 AM, Simon wrote:
> >On Nov 22, 2005, at 9:09 AM, C. Garrett Goebel wrote:
> >
> > > My goals in doing this would be:
> > > o  learn from existing code
> > > o  refactor internals to bring roughly into line with PBP
> > >    submitting doc and code patches to maintainers
> >
> >This all sounds very helpful...
> >
> > > o  refactor interfaces where needed and submit to CPAN under PBP::*
> >
> >... except for this part.
> >
> >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.

Like Perl6::* ?

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. I assume I am not
alone in this.

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

With PBP::, when I head over to http://search.cpan.org, type in Getopt,
and am faced with 30+ modules, I'd at least be able to quickly focus in on
the ones in the ^PBP:: namespace.

That being said, I'm not wedded to PBP::. But I'm not yet convinced that
it'd be unwise to use it.


> >For example, if you rewrite a command-line options parser, it would
> >be better to file it under Getopt::*, where people looking for an
> >options parser are more likely to find it, rather than PBP::CmdLine,
> >where only people who know there's a PBP implementation are likely to
> >look.

The thought was to change the module name as little as possible...

Which would you prefer:
o  Getopt::CmdLine::PBP?
o  Getopt::PBP::Cmdline
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 second puts PBP modules at a branch of the namespace heirarchy where
it may arguably be easier to find. But fragments the module name
itself, and the PBP designation across namespaces branches.

The last allows all the PBP modules to be found from one starting
point, and otherwise leaves the module name intact.


> I agree with Simon on the PBP:: namespace idea.  Perhaps a separate
> export tag if an alternate interface is suggested by PBP (not that I
> can thing of such a situation right now).

How about all the modules which use global variables for configuration?

Or the older ones which recommend object construction like:
    $t = new Data::Table($data, $header, 0);

My guess is that the interfaces of a large portion of Core and CPAN
modules aren't PBP kosher...

I'm excited to learn of Perl::Critic. Perhaps the first thing I'll try to
do with it is run it against Core Perl modules just to get an idea of what
we're up against.


> It would be nice to have a hint in the code that PBP was used and its
> recommendations for formatting and style should be preserved, but it
> would not necessarily be helpful for existing code to "break" simply
> as a result of an interface changing.

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.

I wouldn't consider asking a maintainer to apply non-backward compatible
changes in a module's interface. PBP::* would be for PBP module
refactoring which makes a break with backward compatibility.

cheers,

Garrett



More information about the PBP-pm mailing list