Re: Please advise before I submit to CPAN
- Original Message
From: Aristotle Pagaltzis pagalt...@gmx.de
I would write that
my $self = shift;
my ( $name ) = @_;
:-)
(To my way of thinking, the invocant is not a positional
argument, so I always pull it out of @_ with a `shift`,
whereas I unpack arguments using list assignment.)
Why does this matter? Aside from being able to do this a touch cleaner:
sub foo {
my $self = shift;
my ($name) = @_;
$self-SUPER::foo($name); # if you're still using SUPER::
...
}
I know this formatting is common, but what practical benefit does it gain? It
almost sounds like how I do this:
my $val = join '-' = @args;
The '=' is something I'm often asked about because I like to visual
distinction
between subject and predicate. Aside from that, I'm unsure what value this
provides other than conforming to a particular coding preference (and it's more
ops, but that's probably not enough for it to be a performance win to avoid it).
(I'm not criticising. I'm genuinely curious to know how this helps)
Cheers,
Ovid --
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://blogs.perl.org/users/ovid/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Please advise before I submit to CPAN
* Ovid publiustemp-moduleautho...@yahoo.com [2010-09-10 08:20]:
From: Aristotle Pagaltzis pagalt...@gmx.de
I would write that
my $self = shift;
my ( $name ) = @_;
:-)
(To my way of thinking, the invocant is not a positional
argument, so I always pull it out of @_ with a `shift`,
whereas I unpack arguments using list assignment.)
Why does this matter? Aside from being able to do this a touch
cleaner:
sub foo {
my $self = shift;
my ($name) = @_;
$self-SUPER::foo($name); # if you're still using SUPER::
...
}
Yes, that’s actually specifically one of the reasons. But the
primary one is the same as any other convention, really, though:
it communicates to skimming reader that this is a method rather
than a function, at a glance. The `my $self = shift;` line is
much more distinct than tucking a $self away on the @_ line
(especially in the rare cases when it is with good reason not
even called $self).
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Please advise before I submit to CPAN
On Fri, Sep 10, 2010 at 1:13 PM, Paul LeoNerd Evans leon...@leonerd.org.ukwrote: On Thu, Sep 09, 2010 at 12:37:43PM -0700, Bill Ward wrote: Yes, but doing so is naughty. Really? Howso? I ask because I do it in a module of mine. http://cpansearch.perl.org/src/PEVANS/IO-Async-0.29/lib/IO/Async/Listener.pm Namely: - # This is a bit naughty but hopefully nobody will mind... bless $handle, IO::Socket if ref( $handle ) eq GLOB; - Even in the comment you admit it's naughty :) but what I meant was taking an object of one type and reblessing it to another. GLOB isn't really an object (well that's debatable, but it's not from GLOB.pm!) so that's kind of a different thing.
Re: Please advise before I submit to CPAN
one surprising aspect of perl is that Cbless affects the object, not
the reference, so it is possible to rebless things, which is handy if
you use package-based state machines
D:\perl -le bless $o=[],'abc';print $o; sub f{$l=shift; bless
$l,'DEF'} f $o; print $o
abc=ARRAY(0x3e5444)
DEF=ARRAY(0x3e5444)
because after C my $self = shift you can bless $self and the
invocant will get reblessed.
So whenever anyone says a Perl object is a blessed reference they're
speaking procedurally, not descriptively. Descriptively, a Perl object
is a reference to a blessed thingy.
(I think that's correct terminology, please correct if wrong)
Re: Please advise before I submit to CPAN
On 10-09-09 02:43 PM, David Nicol wrote: So whenever anyone says a Perl object is a blessed reference they're speaking procedurally, not descriptively. Descriptively, a Perl object is a reference to a blessed thingy. (I think that's correct terminology, please correct if wrong) Yes, Perl is the only language where you can bless your thingy. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. The secret to great software: Fail early often. Eliminate software piracy: use only FLOSS.
Re: Please advise before I submit to CPAN
Hi,
I see the same mistake in this module as in 99% of the modules (including
mine). Why did you write it, with examples of what was wrong with the other
modules. I said with examples.
The fathers of the CPAN nation were wise. They advised a See Also section
which should be very detailed since we never, ahem, write anything without
researching the subject thoroughly.
Were there other modules you could have enhanced?
# causes Illegal seek, but safe to ignore? Euu, well you tell us before you
release.
Did you run Perl::Critic on it?
IMVHO, because formatting issues are so not interesting,
my $self = shift;
my $name = shift;
is much better written
my ($self, $name) = @_ ;
sub get_names # return array of active processes by name
{
...
my @ret = []; #NKH, Hu!
You write:
The above example works but does not really demonstrate the full power
of the module. In a more useful implementation (e.g. using
Parallel::Jobs) the parent thread may continuously monitor all workers'
output and provide management such as spawning new workers or sending
signals to children by their pid. detach() and forget() could be called
from the run_on_finish() callback of Parallel::Jobs, depending on the
child's exit status or output.
That paragraph would totally remove any lust I'd have to use the module! If
you have a better example, give it instead for giving a lower usefulness one.
Then you go:
Note: only one pipe is created, with a pair of filehandles for uni-
directional communication, i.e. from child to parent. Bidirectional
IPC might be a nice enhancement for this module, or it may be an
indication that a more robust solution, such as POE, is called for.
Hmm, well, IMO, think again about the usefulness of the module and if you
should put it on CPAN. Frankly, I am not convinced and as you see above, I did
take some time to look around. Don't get me wrong, The more module authors the
better. Also, the better the documentation, the more users, the better.
Cheers, Nadim.
Re: Please advise before I submit to CPAN
Hi Nadim,
Thank you for all the great suggestions. I really appreciate your honesty,
not to mention the time you took to review the module. I am definitely
going to make most of the suggested changes before submitting to CPAN. In
my research, the modules I saw either didn't quite do what I needed, or
were way too featureful, and therefore cumbersome, for my purposes. That
is, I needed to spawn some independent jobs in parallel, monitor their
output, and make adjustments as these processes were running. Based on
your feedback, I'll try to clarify the description. I'll also add a See
Also section as you mentioned.
I hadn't heard of Perl::Critic, but I am definitely going to give that a
look before proceeding. And, I'll also use Carp, which is definitely the
better solution, although returning undef in most cases was sufficient for
me. I don't think I'll add another pipe, though, for several reasons.
First, it was written to launch jobs that could otherwise be run
independently. The caller might need to terminate a process by sending a
signal, and can also pass any arguments or input at the time the job is
launched. I left this part up to the caller as it's more flexible. The
true value is in being able to monitor the jobs' output. Second, if more
sophisticated IPC / message passing is required, then this is where other
modules such as POE would come in - I don't want to duplicate what they
do.
Can you explain the comment you made here?
sub get_names # return array of active processes by name
{
...
my @ret = []; #NKH, Hu!
All in all, I do think the module fills a niche. I'll submit it to CPAN
after making the improvements you and others have suggested. You've given
me some great pointers, and a lot to think about too. I'll revise the
documentation so that, hopefully, the benefits of using this module are
more clear. Thanks again for taking your time to provide this great
feedback.
cheers,
Kevin
quote who=nadim khemir
Hi,
I see the same mistake in this module as in 99% of the modules (including
mine). Why did you write it, with examples of what was wrong with the
other
modules. I said with examples.
The fathers of the CPAN nation were wise. They advised a See Also
section
which should be very detailed since we never, ahem, write anything without
researching the subject thoroughly.
Were there other modules you could have enhanced?
# causes Illegal seek, but safe to ignore? Euu, well you tell us before
you
release.
Did you run Perl::Critic on it?
IMVHO, because formatting issues are so not interesting,
my $self = shift;
my $name = shift;
is much better written
my ($self, $name) = @_ ;
sub get_names # return array of active processes by name
{
...
my @ret = []; #NKH, Hu!
You write:
The above example works but does not really demonstrate the full power
of the module. In a more useful implementation (e.g. using
Parallel::Jobs) the parent thread may continuously monitor all workers'
output and provide management such as spawning new workers or sending
signals to children by their pid. detach() and forget() could be called
from the run_on_finish() callback of Parallel::Jobs, depending on the
child's exit status or output.
That paragraph would totally remove any lust I'd have to use the module!
If
you have a better example, give it instead for giving a lower usefulness
one.
Then you go:
Note: only one pipe is created, with a pair of filehandles for uni-
directional communication, i.e. from child to parent. Bidirectional
IPC might be a nice enhancement for this module, or it may be an
indication that a more robust solution, such as POE, is called for.
Hmm, well, IMO, think again about the usefulness of the module and if you
should put it on CPAN. Frankly, I am not convinced and as you see above, I
did
take some time to look around. Don't get me wrong, The more module authors
the
better. Also, the better the documentation, the more users, the better.
Cheers, Nadim.
Please advise before I submit to CPAN
Hi everyone, I was going to submit a new module to PAUSE, but first I'd love to get any and all feedback from those more experienced than myself. The module currently resides at the URL below - please have a look at the readme, the POD documentation inside the module, and, of course, the code itself and let me know if you have any suggestions before I upload. If you think the module should be renamed, please provide your suggestions. http://www.26a.net/blog/show/Alpha_Launch_of_ParallelSupervisor_Perl_Module.html Thanks in advance! -- Kevin Semande perl...@26a.net
