<html>
<body>
<font size=3>At 11/22/2005 09:39 AM, you wrote:<br>
<blockquote type=cite class=cite cite="">On Nov 22, 2005, at 9:09 AM, C.
Garrett Goebel wrote:<br><br>
> My goals in doing this would be:<br>
> o learn from existing code<br>
> o refactor internals to bring roughly into line with PBP<br>
> submitting doc and code patches to
maintainers<br><br>
This all sounds very helpful...<br><br>
> o refactor interfaces where needed and submit to CPAN under
PBP::*<br><br>
... except for this part.<br><br>
I would urge you to consider posting these modules into the <br>
namespaces that make sense based on what the modules do, rather
than <br>
grouping them together based on an aspect of their
implementation.<br><br>
For example, if you rewrite a command-line options parser, it would
<br>
be better to file it under Getopt::*, where people looking for an
<br>
options parser are more likely to find it, rather than
PBP::CmdLine, <br>
where only people who know there's a PBP implementation are likely
to <br>
look.<br><br>
Just my $0.02...<br><br>
-Simon<br>
</font></blockquote><br>
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).<br><br>
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.<br><br>
# use PBP qw(layout references regexp);<br><br>
-Rob<br><br>
<x-sigsep><p></x-sigsep>
<font size=3>Rob
Biedenharn<x-tab> </x-tab>
<Rob_Biedenharn@alum.mit.edu><br>
(C) 513-295-4739<br>
(H)
513-677-2172<x-tab>
</x-tab>
<a href="http://alum.mit.edu/www/rob_biedenharn/" eudora="autourl">
http://alum.mit.edu/www/rob_biedenharn/<br>
</a></font></body>
</html>