[San-Diego-pm] Meeting Notes - 15 April 2010

Chris Grau chris at chrisgrau.com
Mon Apr 26 09:30:32 PDT 2010


=head1 NAME

SanDiego::Meeting - Meeting of the San Diego Perl Mongers

=head1 DATE

Thursday, 15 April 2010, 19:00 - 21:00

=head1 LOCATION

The offices of Anonymizer, San Diego (Sorrento Valley), Calif., USA

L<http://anonymizer.com/>

Thanks for the use of the room and for the food from Rubio's!

=head1 DESCRIPTION

This is a simple meeting recap, conveniently written in pod so everyone
can read it in whatever format they prefer.  If you lack an appropriate
formatter, well, you can always write one.  As an added bonus, if you're
using a decent MUA *cough*Mutt*cough*, a formatter is only a few
keystrokes away:

    macro pager ,pd "<pipe-message>pod2text<enter>"

=head1 ATTENDEES

April's meeting was sparsely attended.  It was assumed everyone was
still attempting to digest Damian Conway's presentation of I<The
Twilight Perl> last Thursday, which was well attended.

=over

=item * Cathy

=item * Manny

=item * Michelle (Happy Birthday!)

=item * Jeremy (Thanks for hosting)

=item * Chris (Me)

=item * Brian

=back

=head1 TOPICS

=head2 Loading User-Defined Plugin Modules

Manny is working on a plugin system for a Perl-based blogging
application he's hacking on.  He queried the group for advice on how to
implement such a system.  The C<Module::Pluggable> module
L<http://search.cpan.org/dist/Module-Pluggable/> was recommended as a
solution from the CPAN.

However, this being a Perl Mongers meeting, we had to take the time to
discuss other methods, including how we'd roll our own solution.  For
example, a simple way of adding plugin support would be to implement
something like this:

    for my $module ( glob "$plugin_dir/*.pm" ) {
        do $module;
    }

Plugin authors would place their modules in a known, or configured,
location.  The C<do> statement would evaluate the file, running any code
and defining any packages or subroutines contained in the plugin files.
By using C<do> instead of C<require>, plugin files can be re-read
(without modifying C<%INC>) in running code, such as in a mod_perl
environment.

The Template Toolkit system has a mature and flexible method of defining
and loading plugins L<http://search.cpan.org/perldoc?Template::Plugin>,
which is worth evaluating as a potential solution.  Plugins inherit from
a common class and may be located anywhere within the C<@INC> search
path.  The trade off is that the developer or user must explicitly load
each plugin before it can be used; however, for Template Toolkit, this
is a desirable behavior.

=head2 I<The Twilight Perl>

I spent about half the meeting reviewing each of the concepts presented
in Damian Conway's I<The Twilight Perl>
L<http://damian.conway.org/Seminars/Twilight.html> last week.  This was
a fun review for those who attended the presentation.  However, for
those who weren't able to attend, I did not do it justice.

While I have decent notes from the presentation, posting them to the
list begins to border on plagiarism.  However, I'll be more than happy
to discuss each concept at future meetings or in the IRC channel
(#SanDiego.pm on Freenode).

=head1 NEXT MEETING

Thursday, 20 May 2010, 19:00 - 21:00

Tentatively planned is a presentation on and demonstration of the
awesome new features found in Perl 6 using Rakudo.

=cut


More information about the San-Diego-pm mailing list