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.
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:
sub setStdout { my $new = shift; return select( $new ); }
sub usleep { my $time = shift; return select undef, undef, undef, $time; }
Of course, IO::Select does a much better job of dealing with this form.
|
|---|