--- Ofer Nave wrote:
> Here's the POD for my new Parallel::Simple module:
Interface
---------
To me, offering both:
Parallel::Simple::run()
and:
Parallel::Simple->run()
just makes the interface bigger -- more for the user to read and
grok -- without any benefit (at least, none I can see). Suggest
you drop the second form (which does not currently work correctly
because the class name is passed as the first parameter and is not
being shifted). Ditto for offering the run() synonym for prun().
Naming. I wonder if your:
{ use_return => 1 },
is the recommended Perl style for named parameters? I thought not
until I noticed HTML::Parser uses this style. Alternatives are
CamelCase style (a la XML::Parser, for example):
{ UseReturn => 1 },
or dash-option style (a la CGI, for example):
{ -use_return => 1 },
I'm damned if I can find a reference clearly stating which one of
these three styles is preferred. Can anyone point me to a reference
on this?
Your example:
die( Parallel::errplus );
should be written:
die( Parallel::errplus() );
to avoid bareword error under use strict.
Implementation
--------------
Just a couple of micro-optimizations I noticed.
This function synonym:
sub run { prun( @_ ) }
is better implemented as:
sub run { &prun }
This special form of sub call makes current @_ visible to called
subroutine. I suppose the primitive-obsessed might prefer:
*Parallel::Simple::run = \&prun;
In a couple of places, I noticed:
/HASH/o
The /o modifier is meaningless here and should be removed.
You get the return code here:
$child_registry{$child}[1] = $? >> 8;
yet miss getting if it died hard from a signal via:
$? & 127;
Further getting whether it dumped core via:
$? & 128;
is probably overkill. Not sure how this would affect your interface,
but I've seen cases where a process crashes yet returns a $? >> 8
of zero while $? & 127 is 11 (SIGSEGV).
HTH,
/-\
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
