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

I respectfully disagree.

Named parameters means I don't have to pass a string of undefs because one particular call doesn't use those parameters. APIs using positional parameters have a way of requiring difficult upgrade path.

It's also self-documenting -- instead of a list of variables, each variable is named, which can only help the future software forensic expert.

Many years ago, I wrote a User Interface program in C, and one of the things that I used was lots of parameter passing, knowing enough that global variables were not the answer. Eventually, I had a couple of routines that required a dozen or so parameters, and as the code matured into a lovely congealed mass of spaghetti, I began to dread getting in there to fiddle with calls to that code, precisely because I had to add 'just one more' parameter at the end.

The alternative could have been to pass in a pointer to a struct, which is more or less a hashref, but I wasn't secure enough in my abilities to do that. Too bad, because it would have been the right thing to do, just as using a hashref is the right thing to do.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

  • Comment on Re^5: When every microsecond counts: Parsing subroutine parameters
  • Download Code

Replies are listed 'Best First'.
Re^6: When every microsecond counts: Parsing subroutine parameters
by blazar (Canon) on May 18, 2008 at 15:56 UTC
    Named parameters means I don't have to pass a string of undefs because one particular call doesn't use those parameters. APIs using positional parameters have a way of requiring difficult upgrade path.

    I personally believe that named parameters can indeed be very useful. In this sense Perl 6 with its extremely complete and flexible sub signatures is fantastic. Perl 5 is also charming for the far reaching semantics it can get out of its very simple mechanism of parameter passing, allowing one to emulate named parameters.

    However, as far as your remark about "a string of undefs" (I presume you really mean "list") is concerned, I would like to point out that while the fact that several commas "collapse" into one fits perfectly well into Perl's semantics, I have occasionally desired say $x,,,,$y to be a shortcut for $x,undef,undef,undef,$y.

    --
    If you can't understand the incipit, then please check the IPB Campaign.
[reply]
[d/l]
[select]
      I have occasionally desired say $x,,,,$y to be a shortcut for $x,undef,undef,undef,$y.
      Be happy that you need the undef! Counting the nothings between the commas must be one of the most frustrating exercises ever devised.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
[d/l]

        I personally believe that's why I occasionally desire it, as opposed to constantly.

        Having stared at csv files with empty fields, I know what you mean, except that in that case the task can even be facilitated by the formatting of some fields. However there's a difference between say, fifteen adjacent commas and two or three. Anyway that's not something to be changed, so it's not worth discussing either. OTOH I often feel the need for some syntactical sugar to indicate a "missing something," whereas undef, however short, is somewhat obtrusive: Perl is already a hell to parse, but how 'bout a lonely minus sign?

        my $x = foo(42,-,-,'cool');

        [download]
        --
        If you can't understand the incipit, then please check the IPB Campaign.
[reply]
[d/l]
[select]

      Brilliant. Yet another clever way that Perl takes care of things automagically.

      I hadn't realized that, because I wasn't thinking Perlishly enough. Thank you.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

[reply]

        I personally believe there's been some misunderstanding. Granted, I'm glad to receive your thanks, but I can't remember having pointed out any "clever way that Perl takes care of things automagically" in the post you're replying to. Did I?

        --
        If you can't understand the incipit, then please check the IPB Campaign.
[reply]
[d/l]
Re^6: When every microsecond counts: Parsing subroutine parameters
by BrowserUk (Patriarch) on May 18, 2008 at 18:53 UTC
    Named parameters means I don't have to pass a string of undefs because one particular call doesn't use those parameters.

    I don't suppose you have any concrete examples you'd care to share?

    APIs using positional parameters have a way of requiring difficult upgrade path.

    And yet, other than tcl, I can't find reference to a single other language that has felt the need to implement named parameters?

    Don't take me wrongly. The are absolutely some calls in many APIs (from many languages) that would benefit from this kind of self documentation.

  • CreateWindow() with its 11 parameters, some of which are themselves structs or bit-fileds is an obvious candidate.
  • CreateFile() with its 7 parameters including 4 bit-fields is another.

    But by and large, most of them are constructors. And where APIs regulary require the user to supply a list of undefs in order to use the call, architypically select undef,undef,undef, 0.1; these are generally and widely acknowledged, even by their authors, as being "ones that got away".

    With most functions that sometimes require more than 3 parameters, there is a 'natural ordering' that means that any omitted parameters will come at the end. Eg. substr, splice, read. Even in a function rich API like Perl's there are suprisingly few calls that require more than 3 args, and almost none that require the use of placeholders for distinct functionality.

    And that's the clue for me. If an API (beyond constructors), cannot be designed such that any omitted arguments fall at the end, then it is really two (or more) apis that have been conflated. select is the prime example as noted above, and it isn't hard to see how to change that:

    • my $old = setStdout( $new ); 
      sub setStdout {
    my $new = shift;
    return select( $new );
}

      [download]
    • usleep( 0.1 ); 
      sub usleep {
    my $time = shift;
    return select undef, undef, undef, $time;
}

      [download]
    • select $read, $write, $error, $time );

      Of course, IO::Select does a much better job of dealing with this form.

    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]
        I don't suppose you have any concrete examples you'd care to share?

      Nope -- none to hand. That doesn't lessen my assertion that named parameters are a fine alternative to positional parameters, for the reasons I've already listed. 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.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

[reply]
        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.
[reply]
[d/l]
      And yet, other than tcl, I can't find reference to a single other language that has felt the need to implement named parameters?
      I can think of Common Lisp, Ruby, and Python off the top of my head...
[reply]

        1. Ruby has to fake keyword args using a hash just like perl.
        2. Python has proper keywork args.

          I just never got into Python enough to reach the point where I would have noticed. (Seems it wasn't implemented until v2 anyway and thats probably after I last looked at it.)

        3. Lisp in all its many forms does my head in.

          I believe that keyword arguments are considered an extension. Still, that is implemented, so I defer.

          Just be really careful that you don't need to pass a value that looks like a keyword (eg:xxx), because things get really confusing really fast.

        So that makes 3. Four if you count Perl 6.

        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