Buddy Burden wrote:
True, but my own thoughts were already somewhat in tune with Andrew's suggestion. Having two names was cluttering the docs, with the only benefit being the lack of the redundant 'p' on fully-qualified calls.Ofer,
With all due respect to Andrew, please remember that his is but one opinion.
I've also now removed any traces of the run() synonym. You're right - why complicate things with no benefit.
I didn't see anything wrong with the concept. Personally I would have done it the other way around (i.e. make prun a synonym for Parallel::Simple::run), but that's a minor point. To me, run is a perfectly reasonable name for the function when fully qualified, but it makes sense not to export (even only when requested) such a simple function name into the global namespace. In fact, I might go even further and name it par_run or somesuch. But that's just me.
Personally, I almost always prefer parens on function calls. For built-ins, my philosophy is more complicated, and I won't go into it here. :)Oh, and I do agree with the comments about using
*Parallel::Simple::run = \&prun;
instead of the way you've done it. That's the proper way to create a "synonym" IMHO.
What's funny is that I actually like the parentheses, since I strive to avoid any ambiguity, but I left them off here because I was trying to make my first CPAN module as perl-ish as possible - when in Rome and all that. I'll add parentheses back on.
Using the "without parends" style is perfectly valid. It won't cause a bareword error unless the subroutine is undefined. Many people prefer it. I personally use both ... I know that would drive many people crazy as inconsistent, but I actually feel that sometimes it seems more natural with and sometimes without. Bottom line is go with whichever you personally prefer.
I've added them for the docs, since the point of docs is to make things as clear as possible. Users can always do their own thing, as usual. :)
No, I'm familiar with the make-up of the 16-bit return value of the system call. What I want to learn more about is the possibility that a process could crash and yet return a 0 exit code. I had not thought that possible, and hence, had seen no need to test for $? & 127.Seriously? Is there anywhere I can learn more about this?
Try
perlfunc system
just for a start.
-ofer
