Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: RFC: A Primer on Writing Portable Perl Programs

by brian_d_foy (Abbot)
on Nov 01, 2006 at 09:03 UTC ( #581636=note: print w/ replies, xml ) Need Help??


in reply to RFC: A Primer on Writing Portable Perl Programs

You say to avoid using $^O, but then recommend using File::Spec, which uses $^O to do what you said not to do. It's not a bad technique. 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.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review


Comment on Re: RFC: A Primer on Writing Portable Perl Programs
Select or Download Code
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."
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.

    Frank Wiles <frank@revsys.com>
    www.revsys.com

      I agree completely! That is the point I was trying to make.
      *=========================================================================* | Dr. Tim Maher, CEO, Consultix | Email: tim@consultix-inc.com *=========================================================================*
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.

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 *=========================================================================*
Re^2: RFC: A Primer on Writing Portable Perl Programs
by tilly (Archbishop) on Nov 01, 2006 at 23:51 UTC
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.

Re^2: RFC: A Primer on Writing Portable Perl Programs
by ikegami (Pope) 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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://581636]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2014-08-23 05:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (172 votes), past polls