Why is a hyphen often used as the first character in named parameters?

Historically, because it allowed getopts to be used to parse/validate sub args?

And do the 'good reasons' (if any exist) outweigh the inconvenience of defeating part of the usefulness of the fat comma operator?

No. (Because there are no good reasons.)

Additionally, the justifictions for named parameters are overstated.

• If the sub/method is new to you, then you'll need to look up the names of the parameters just as you would the ordering.
• If it is an api you use recurrently, but infrequently, even if you remember what the parameters are, you'll still need to look up the api to remind yourself of the parameter naming conventions for this particular module.

  Is is debug or <c>-debug or Debug or DEBUG or -Debug or debug_on or debugOn or -debug_on or -DebugOn or DebugOn or ...

• If it is an api you use all the time, you'll probably use the named parameters in the same order every time and the names will become redundant.
• If you are a casual reader (or new maintainance programmer) unfamiliar with the api, then the named parameters will likely cause you to believe you understand what the api does without actually referencing the documentation.

  And on historical evidence, 7 out of ten times you will be wrong.

  Programmers have been, are, and likely always will be notoriously bad at naming variables. There is no reason to believe they'll be any better at naming parameters.

• The affect named parameters have upon performance is underestimated.

  First, you construct a list; then you construct a hash from that list; then you have to destructively decompose the hash in order that you can verify that the caller didn't misspell one or more parameters. Because if you don't check for typos, as many modules do not, then you silently adopt defaults for parameters that the programmer thought he had specified.

  (NB: And all of that is before, and in addition to, validating the actual parameters themselves.)

  "Performance doesn't matter" many will claim. But for the short, frequently-called methods that typify OO code, all those little bits add up.

  And "Programmer efficiency is more important than program efficiency". But remind yourself of that the next time you spend days trying to track down a bug because you supplied the right value with a minor misspelling of a an unchecked parameter name.

Just my 2 cents on the matter.

First, I love named parameters, but use both styles -- named and unnamed. It all just boils down to the level of confidence that you have in the values, and respective ordering, that have been passed. If it is an internal function, method, subroutine, whatever that you are certain of the parameters, then named parameters are not really needed. However, if it is an interface exposed to the public where you are not certain of the ordering, then named parameters may be in order.

Next, there is no substitute for checking what is passed. Unexpected, or bad, programmatic behaviour happens when parameters and return codes are not checked. Never assume the sky is always blue.

Finally, BrowserUk is correct in saying that all the bits add up. One needs to take in to context what is being done and who is doing it. Memory footprint, CPU usage, and overall responsiveness of an application is just as important as what the application accomplishes. Too often one comes across a "Swiss army knife" application that does everything but does nothing well because of its' design. Personally I would rather have an application that does one thing really well than an application that tries to do many things and is hard to maintain.

Like I said, just my two cents.

--Poet

However, if it is an interface exposed to the public where you are not certain of the ordering, then named parameters may be in order.

You really think that remembering the ordering of parameters is harder than remembering the names, spelling, casing, presence or absence of leading hyphens etc?

Do you you use (or just know of) a non-constructor api that you feel really benefits from the use of named parameters?

---

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.

maybe in part because the fat comma does work its quotish magic for hyphenated parameter names:

use strict;
use warnings;

params (-first => 'first', -second => 'second');

sub params {
    my %params = @_;
    
    print "$_: $params{$_}\n" for sort keys %params;
}
[download]

Prints:

-first: first
-second: second
[download]

and thus disambiguates somewhat between parameter names and values? The magic only works for a leading -, anywhere else it turns into a subtraction operator with less desirable results!

Should that behavior be considered to be at odds with perlop? The POD enumerates what would be considered fat-comma-quotable.

Maybe it's an example of the notion that perl is the ultimate authority on Perl.




Dave

I was worried about even posting the reply because I haven't a good story for why it should work apart from Perl DWIMery. As you point out it's not documented as providing that behaviour in any obvious place.

On the other hand it would break a huge amount of code should that behaviour change so I'd guess it ought be safe enough to use.

True laziness is hard work

I don't think its related to fat-comma, observe

$ perl -le print-localtime
-Tue Jun 28 00:16:25 2011