batkins has asked for the wisdom of the Perl Monks concerning the following question:

Is there any advantage to using dashes in named parameters as arguments? Tk uses them exclusively (e.g. $widget->pack(-expand => 1)) whereas other modules, like Net::SMTP, don't (e.g. Net::SMTP->new(Debugging => 1)).

Is there any reason to use dashes? I think I read somewhere that dashes prevent the names of the parameters from interfering with the names of existing symbols. Is this true?

TIA, Bill

milkbone - perl/tk instant messaging - it's the only way to fly

You know anyone who'll debug two million lines of code for what I get this job?
- Dennis Nedry

Replies are listed 'Best First'.
Re: Named Parameters - Dashes or No?
by Paladin (Vicar) on Jul 24, 2003 at 19:21 UTC
    The reason that Tk uses dashes, is that Tk was developed for the TCL language, and TCL uses dashes in it's commands for options. I'm not sure what symbols you are refering to that may be interfered with, but in any case, I can't see how that may happen. Usually one would assign the list of options to a localized hash in the sub, and use them from there, which shouldn't interfere with anything.
[reply]
      Well, if you had a situation like this: sub name { ... } somefunc(name => '122323223') would the existence of the name sub cause problems with the hash?
      milkbone - perl/tk instant messaging - it's the only way to fly

      You know anyone who'll debug two million lines of code for what I get this job?
      - Dennis Nedry

[reply]

        Try it to see what happens. Try it with B::Deparse to see what Perl thinks it is.

        It turns out that the fat comma autoquotes the preceding bareword. No problem; that's what you want.

[reply]
Re: Named Parameters - Dashes or No?
by ihb (Deacon) on Jul 24, 2003 at 20:42 UTC

    This is my take, which really is a guess, but hopefully a qualified one.

    I'll first pull out two strings from perlop:

    • About =>: As of release 5.001, it also forces any word to the left of it to be interpreted as a string.
    • About unary -: One effect of these rules is that -bareword is equivalent to "-bareword".

    Before 5.001, using an unary - with a bareword in the argument list was a trick to not have to quote it. As of 5.001, this trick was no longer needed since => already did that for you. So I believe that the dash style is a historical left-over.

    ihb
[reply]
[d/l]
[select]
      Yeah, but it was much later than 5.001 where things like 
          shift => "foo"

      [download]

      no longer resulted in a warning that it was ambigious. That warning is, IIRC, the reason Tk uses dashes.

      Abigail

[reply]
[d/l]
Re: Named Parameters - Dashes or No?
by Limbic~Region (Chancellor) on Jul 24, 2003 at 19:22 UTC
    batkins,
    Thinking out loud here...

    If the options were not going to be parsed then no. The _ usually preceeds a variable or a sub in an OO module to indicate it is private and not meant for public consumption. A dash is usually used as a command line argument.

    So, if the module were going to be passing your arguments to something like Getopt::Long for instance, it would make perfect sense. I haven't played with Perl/Tk yet, but that would be my guess.

    Cheers - L~R

[reply]
Re: Named Parameters - Dashes or No?
by TomDLux (Vicar) on Jul 25, 2003 at 14:48 UTC

    Do you like the idea of dashes? Use them!

    Don't like them? If you're using Tk, you need to use them anyway, but in your own code, you can do what you want.

    --
    TTTATCGGTCGTTATATAGATGTTTGCA

[reply]
      I don't like them. I just wanted to be sure there wouldn't be any consequences of taking them out.

      Thanks, everyone. Out they go.

      milkbone - perl/tk instant messaging - it's the only way to fly

      You know anyone who'll debug two million lines of code for what I get this job?
      - Dennis Nedry

[reply]

Back to Seekers of Perl Wisdom