jpie...@cpan.org wrote:
I was wondering what the rationale for staking out a top-level namespace to
match
your username on CPAN is?
In the past, I went through the process and put one module into the
global CPAN name space -- Math::TriangularNumbers:
http://backpan.perl.org/authors/id/D/DP/DPCHRIST/
When I wanted to automate the module document generation, release, and
distribution processes for this and all my other Perl code, I looked at
Module::Build, etc.. Being an old-school machine code, assembler, C,
and CLI kind of guy, and not to mention lazy, for better or worse I
decided to stick with the ExtUtils::MakeMaker I knew and loved, and
figure out how to extend it. But, I knew I was treading on old, thin
ice. As I understand it, using your CPAN author ID as a top-level
module namespace (e.g. Dpchrist::*) is the convention for personal
and/or experimental code:
http://search.cpan.org/~dpchrist/
So, I copied the contents of Math::TriangularNumber into
Dpchrist::TriangularNumber and began working on that and
Dpchrist::Module. As work progressed, I created more Dpchrist::*
modules. I later deleted Math::TriangularNumbers from CPAN, but the
ghost of an evil twin that I created through an improperly named
distribution tarball uploaded to CPAN haunts me to this day:
http://www.cpantesters.org/distro/M/Math-TriangularNumbers-r.html
Please understand that there is software (1x effort), there is systems
software (3x effort), there is software product (3x effort), and there
is systems software product (10x effort):
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
According to Brooks, Dpchrist::* is software (at best). When people use
a module from the global CPAN namespace, they deserve systems software
product. I can't afford that level of effort.
My knowledge and skills with Perl are neither advanced nor current, and
my code reflects it. If you're shopping CPAN for canned solutions to
problems you need to solve, you're better off finding out how better
Perl programmers than myself have already solved those problems and
using their solutions and/or modules.
If and when some portion of the Dpchrist::* code qualifies as Modern
Perl systems software product, it would then be appropriate to obtain
consensus from the CPAN module authors community as to the most proper
subdivision and naming of the work, including the possibility of
incorporating it into already existing module(s), and do so at that time.
<rant>
But to be blunt, what is missing in Perl is a complete, consistent, and
professionally designed, constructed, documented, tested, and supported
library. (Python is supposed to excel in this regard, but a dirty old
hack like me could never use a whitespace sensitive language.)
Hell, we don't even have a current programmer's reference guide! Where
is Programming Perl, 4 e.? I've got money burning a whole in my pocket
for that book! ;-)
</rant>
I would welcome help in improving my Perl skills, Perl code, and/or
usage of CPAN. Please understand that I'm no computer demigod, and that
I work on Perl on a time-permitting basis. I am currently trying to get
Bundle::Dpchrist to pass all the CPAN Testers smoke tests:
http://www.cpantesters.org/author/D/DPCHRIST.html
Also on the wish list:
1. Better documentation and 100% coverage.
2. Better test scripts and 100% coverage.
3. Object orientation via Moose.
4. Databases via DBIx::Class.
5. Winning numbers for the next California Lottery.
David
p.s. I am cc'ing the beginn...@perl.org and Module-Authors@Perl.Org
mailing lists because I know I have more to learn and because other
people might have some good comments (lists.cpan.org seems to be down at
the moment):
http://www.mail-archive.com/beginners%40perl.org/
http://www.mail-archive.com/module-authors@perl.org/
