On a more general note, it is my preference that any time a function (or method) accepts more than one parameter then it is time to use "named parameters" to prevent future headaches.

For example:

#!/usr/bin/perl -w use warnings; use strict; sub processDir { my $args = shift; # note, default for shift here is @_; my $ret = qx($args->{script} $args->{dir}); chomp($ret); print qq(Output:"$ret"\n) if $args->{verbose}; } # Normally via environment variable my $script = "echo -e"; # Normally via glob and processing in this script my @dirs = qw(dir1 dir2 dir3); # Normally via Getopt::Long my $verbose = 1; for my $dir (@dirs) { # Do some stuff, then: processDir( { dir => $dir, script => $script, verbose => $verbose +} ); # which would be exactly the same as: processDir( { script = > $script, dir => $dir, verbose => $verbose + } ); # or this: processDir( { verbose => $verbose, script => $script, dir => $dir +} ); # or any other combination you can think of. }

There is much, much more that can be said about this, but knowing about the idea should give you the start for some very interesting research.

Note: Yes, I know I have left out a LOT of potential gotchas in this very crude example. But I feel the essence is clear and a minimal amount of research should reveal a wealth of information on the concept that will stand OP in good stead for a long time to come.

Update: Another advantage of named parameters is that with a little thought you can deal with the situation where you might start out with a single parameter passed in the normal way, but then allow for named parameters in the future. This example is taken from (my module) DateTimeX::Fiscal::Fiscal5253 (Please read the docs on CPAN to understand just exactly what this allows):

sub contains { my $self = shift; my %args = @_ == 1 ? ( date => shift ) : @_; $args{date} ||= 'today'; $args{style} ||= $self->{_style}; croak 'Unknown parameter present' if scalar(keys(%args)) > 2; ... }

You will find several examples of how I use this technique in the source.

The answer to the question "Can we do this?" is always an emphatic "Yes!" Just give me enough time and money.

In reply to Re: Best Practice: How do I pass option parameters to functions? by boftx
in thread Best Practice: How do I pass option parameters to functions? by An_Idea_Within

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.