|
in reply to Re^5: When every microsecond counts: Parsing subroutine parameters
in thread When every microsecond counts: Parsing subroutine parameters
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 );
}
- usleep( 0.1 );
sub usleep {
my $time = shift;
return select undef, undef, undef, $time;
}
- 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.
|
Re^7: When every microsecond counts: Parsing subroutine parameters
by talexb (Chancellor) on May 18, 2008 at 20:18 UTC
|
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] |
|
|
| [reply]
[d/l] |
|
|
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);
| [reply]
[d/l]
[select] |
|
|
Re^7: When every microsecond counts: Parsing subroutine parameters
by educated_foo (Vicar) on May 19, 2008 at 01:47 UTC
|
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] |
|
|
| [reply]
[d/l]
[select] |
|
|
Just for the sake of completeness, we get to five if you count R, which allows one to intersperse positional and named parameters in a remarkably laissez-faire manner. It's not exactly a general-purpose language, though.
| [reply] |
|
|
|
|
I believe that keyword arguments are considered an extension. Still, that is implemented, so I defer.
Assuming you're talking about Common Lisp, keywords alone and keywords as argument specifiers are AFAIK both required parts of the spec, not just optional extensions. Other Lisp dialects can and do have different ideas - the only other relatively widely used Lisps, these days, are Scheme and Emacs Lisp (which both don't have keyword args).
| [reply] |
|
|
|
|
|
|
