At YAPC, I told Nat I wanted to get involved with modules-related work
for Perl 6. To that end, I've put together a bit of a list of what I
think needs to be done in that area. The list appears below, in POD
format. If you're interested in being involved in this stuff, or just
have comments, please follow up to [EMAIL PROTECTED], which is
probably the most suitable place available to us.
K.
=head1 NAME
Perl 6 Modules Plan
=head1 INTRODUCTION
Fundamental premise: almost all Perl 5 modules will be rewritten in Perl 6 at
some point in the future.
When we started writing modules for Perl 5, it was a new experience.
We've learnt a lot since then. Let's take advantage of that knowledge
and try to apply it to the Perl 6 rewrite.
=head1 THINGS THAT NEED DOING
=head2 Help people rewrite their modules
... and help them rewrite them B<better> than before. There should be
tools, guidelines and processes to assist authors in writing quality modules.
See also [EMAIL PROTECTED]
Specifically:
=over 4
=item Style guide
See L<perlmodstyle>
=item Naming guidelines
See below.
=item h2xs replacement
See L<ExtUtils::ModuleMaker>
=item Documentation assistance
Style guide? Improve auto-generated doc stubs? Team of doc
reviewers/editors/etc?
=item Testing tools
See L<Test::Simple>, L<Test::More>, L<Pod::Tests>, CPANTS, etc.
=back
=head2 The stdlib/SDK/??? issue
What goes in the standard library? What about SDKs? We need some
guidelines and processes in place for this. Mostly a documentation job.
=head2 The role of CPAN
Will CPAN's role remain unchanged? Will there be a separate space for
Perl 6 modules (6PAN)?
If we do want to make changes to CPAN then Perl 6 gives us an
opportunity for a "flag day" if we need one. OK, not an actually flag
*day*, but at least a point where we can say "Things are different for
Perl 6" and to hell with backwards compatibility ;)
This is not strictly a modules issue, so see also [EMAIL PROTECTED]
=head2 Namespace cleanup/naming conventions
The Great Perl 6 Module Rewrite also gives us a good opportunity to clean
up module namespace, if necessary.
=over 4
=item Document namespace guidelines
This is a good opportunity to iron out some namespace wrinkles. First
step is to figure out what's already there on CPAN and can be documented
as current "best practice" (eg. silly modules go in Acme::*, network
protocols in Net::*).
Similarly, figure out areas where it's a huge mess and make a note of them
(eg. Date/Time, WWW/CGI/HTML/etc), then see if we can get any consensus
on how they should be sorted out (see notes below on getting authors of
similar modules working together).
The resulting document ("module naming guidelines") will be useful both
for authors trying to figure out what to call their module, and for
those who get asked for advice on the topic (so they can't point and say
"RTFM", thus saving themselves lots of work in explaining every time).
=item Clarify role of [EMAIL PROTECTED]
Currently, [EMAIL PROTECTED] is the arbiter of module naming. However,
the process by which it operates, and the ways in which it determines
what is and isn't suitable naming, are opaque to the vast majority of
module authors.
This needs fixing. The naming guidelines (above) may help somewhat, by
lessening the [EMAIL PROTECTED] workload.
=back
=head2 Get authors of similar modules working together
The [EMAIL PROTECTED] list is for authors of date and time modules to
talk about issues relevant to their field. Topics have included naming
conventions, common APIs, etc. It would be really good to have similar
lists for other groups of authors, including:
=over 4
=item *
Database modules
=item *
WWW-related modules
=item *
XML modules
=item *
Templating modules
=item *
Developer tools (Devel::*, Test::*, etc)
=back
The members of these lists could co-operate and collaborate to create
more integrated sets of tools.
=head1 AUTHOR
Kirrily "Skud" Robert <[EMAIL PROTECTED]>
--
Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/
She had a pretty gift for quotation, which is a serviceable substitute for wit.
