|
Re^2: RFC: A Primer on Writing Portable Perl Programs
by ides (Deacon) on Nov 01, 2006 at 14:54 UTC
|
True, but I think the point he was trying to make is avoid using $^O whenever possible. First off avoid using it in your own code when a suitable CPAN module exists. I'd say the second step would be to abstract out your use of it into your own independant module to localize the OS specific-ness to as few places as possible.
Nothing is worse than having huge if/else trees of OS specific code littered throughout a program.
| [reply] |
|
|
I agree completely! That is the point I was trying to make.
*=========================================================================*
| Dr. Tim Maher, CEO, Consultix
| Email: tim@consultix-inc.com
*=========================================================================*
| [reply] |
Re^2: RFC: A Primer on Writing Portable Perl Programs
by xdg (Monsignor) on Nov 01, 2006 at 15:08 UTC
|
You say to avoid using $^O, but then recommend using File::Spec
I took the original advice as another "don't reinvent the wheel" caution. I.e. look for a module that already does things portably rather than try to write it again from scratch. It's a thought that applies more for program authors than for module authors, who do need to concern themselves with OS-specific behaviors if they're planning on distributing things to CPAN.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
Re^2: RFC: A Primer on Writing Portable Perl Programs
by Velaki (Chaplain) on Nov 01, 2006 at 13:31 UTC
|
To extend that, you could always set up a collection of dispatch tables in your own code, and simply select the appropriate mapping using $^O. Then you code using your SKU mapped functions. It might not be the best, but you could always make it a module, and use it where needed.
Just a thought,
-v.
"Perl. There is no substitute."
| [reply]
[d/l] |
Re^2: RFC: A Primer on Writing Portable Perl Programs
by tilly (Archbishop) on Nov 01, 2006 at 23:51 UTC
|
| [reply] |
Re^2: RFC: A Primer on Writing Portable Perl Programs
by yumpy (Sexton) on Nov 01, 2006 at 17:49 UTC
|
The point of avoiding explicit use of $^O was to prevent
cluttering up the code, which isn't an issue when accesses to that variable are confined to a module. But I agree that you can't always avoid OS-specific code, so perhaps the word "minimize" might be a better choice than "avoid".
*=========================================================================*
| Dr. Tim Maher, CEO, Consultix
| Email: tim@consultix-inc.com
*=========================================================================*
| [reply] |
Re^2: RFC: A Primer on Writing Portable Perl Programs
by ikegami (Patriarch) on Nov 02, 2006 at 17:22 UTC
|
Don't forget that File::Spec is a core module, tested and maintained to run on all platforms on which Perl is supported.
| [reply] |
Re^2: RFC: A Primer on Writing Portable Perl Programs
by Anonymous Monk on Nov 02, 2006 at 16:18 UTC
|
You say to avoid using $^O, but then recommend using File::Spec, which uses $^O to do what you said not to do.
His advice was directed at the user of the File::Spec module, not the author of the File::Spec module. If the File::Spec module is any good (as I understand it is), the end user can simply use it without knowing exactly how it works.
It's only when a module doesn't work (in the way you want it to) that you're reduced to groveling through the tedious little implementation details to fix whatever's broken.
At some point you do have to get down to brass tacks and interact with the operating system, or tell Perl how to behave for the particular operating system.
"Avoid <X>" doesn't mean "don't do <X>". It means "don't do <X> if there's another way of doing things". If there's no other way of doing things, his advice (and your criticism) doesn't apply.
| [reply] |
