Re^4: How should named paramater keys be named?

The LWP::UserAgent/WWW::Mechanize API (and especially the WWW::Mechanize::Firefox API) has lots (and lots) of optional parameters, which are mostly filled in as defaults from the object when left out or left alone. The first such example in WWW::Mechanize::Firefox is

$mech->progress_listener( $source, %callbacks )
[download]

... where you specify the callbacks by name instead of by position, as usually, you want only to set one or two callbacks.

The same counts for the ->get() method:

$mech->get( $url, %options )
[download]

Here, the options can specify a target filename where to store the response, whether to bypass the cache etc.. All of these parameters are fairly orthogonal and it wouldn't make much sense to have them positional in my opinion.

Two APIs that constantly trip me up is the DateTime API and the Imager::Color API. The DateTime API wants me to always specify named parameters when I'm calling any function even though the method only allows one parameter and makes sense for only one parameter. The Imager::Color API raises no warning for:

my $blue = Imager::Color->new( 0, 0, 255 );
[download]

... but creates no sensible object either. It wants

my $blue = Imager::Color->new( r => 255, g => 0, b => 0 );
[download]

Comment on Re^4: How should named paramater keys be named? Select or Download Code

Replies are listed 'Best First'.
Re^5: How should named paramater keys be named? by BrowserUk (Patriarch) on Jul 02, 2011 at 08:55 UTC
where you specify the callbacks by name instead of by position, as usually, you want only to set one or two callbacks. Optional arguments are the exception that proves the rule. (IMO :) The DateTime API wants me to always specify named parameters when I'm calling any function even though the method only allows one parameter and makes sense for only one parameter. And that demonstrates the problem with guidelines. There will always be those who apply them religiously without thinking. Cargo-culting of the very worst kind. Another that bugs me is `q()`. The Imager::Color API raises no warning for: ... but creates no sensible object either. I liked the SmallTalk approach to the problem where the names of arguments to methods are effectively a part of the method identifier. Eg. `pen: anInteger for: aHandle medium: aGraphicsMedium` [download] The best bit about this is that the parameter names are checked at compile time. 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]
Re^5: How should named paramater keys be named? by tonyc (Friar) on Jul 13, 2011 at 07:48 UTC
That behaviour of Imager::Color would be a bug, given the documentation. But I can't reproduce it: `tony@mars:.../git/bse$ perl -MImager -le '$c = Imager::Color->new(0, 0 +, 255); print join ",", $c->rgba' 0,0,255,255` [download]	[reply] [d/l]
Re^6: How should named paramater keys be named? by Corion (Patriarch) on Jul 13, 2011 at 07:52 UTC
Maybe the problem was in my subsequent use of the colour - I have to look at the code at home to see what really triggered the behaviour in the program. Looking at the code in Imager::Color, I don't see any reason why it shouldn't behave as the documentation says.	[reply]