in reply to Re^7: When every microsecond counts: Parsing subroutine parameters
in thread When every microsecond counts: Parsing subroutine parameters

I will modify that by saying that if there are just a few parameters to a function, positional parameters will work fine, but if there's a chance that some of the parameters might be optional, a hashref of named parameters is the way to go.

Then I think we are broadly in agreement. Then only areas left for arg negotiation are:

  1. How many parameters there need to be before using named parameters make sense.

    I'd set that to be: more than 4.

  2. The rarity with which the need arises (for non-constructors).

    On the basis of my not so exhaustive attempts to find counter examples, I'd say that the times when it's required purely because of the shear numbers of parameters, is really quite surprisingly rare.

    And, the occasions when it's needed to allow the ommision of placeholder undefs, is rarer still. Try as hard as I might, I find pretty impossible to come up with even a hypothetical good example of where there is no natural ordering that would allow logically optional parameters to be placed after all mandatory and more frequently required optional parameters.

    You need the situation where func( mandatory1, mandatory2, optional1, optional2 ) optional2 is logical when optional1 is not required, and optional1 is required when optional2 is not. I haven't found an example of that outside of conflations like select.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^8: When every microsecond counts: Parsing subroutine parameters
  • Download Code

Replies are listed 'Best First'.
Re^9: When every microsecond counts: Parsing subroutine parameters
by rhesa (Vicar) on May 18, 2008 at 21:48 UTC
    There's one in DBI that annoys me on occasion, and that's do($statement, \%attr, @bind_values);. In my code, I haven't found any use of that method where I needed to pass attributes, but I do have a fair number where I use bind values. Example: 
    $dbh->do('update some_table set some_column=?', undef, $some_string);

    [download]
[reply]
[d/l]
[select]

      Perfect example of a bad api (I'm assuming that your experience of rarely needing \%attr is widespread.)

      Maybe there is scope for the addition of a doBind() to the api that reverses the ordering of the last two parameters. Or just omits the second.

      But named parameters would be no advantage: 

      $dbh->do( 
    sql => 'update some_table set some_column=?', 
    bind => [ $some_string ]
);

      [download]
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Meditations