A colleague was creating an app that used the Net::LDAP module, a module I have been using myself for a very long time now. In the code there was the statement:
my $msg = $ldap->search(bind_dn => $base_dn, filter => $filter);
…that was returning a “Bad filter” error. Turns out there was no problem with the filter text, but there was with the search statement—the parameter label
bind_dn is not a valid keyword for this module.
I did something similar a long time ago, using a parameter label for the
bind() method that actually belonged to
new(). The parameter and value were accepted without comment. It didn’t cause an error, it was just silently ignored since it was totally unexpected.
As I’m sure you know, when passing named parameters to a method, what you are really passing is a hash. So:
filter => $filter
…is really a hash entry with ‘filter’ as the key getting assigned the value from the scalar $filter. Now what you would like is for the method to throw an error if you misspell a key, but for the Net::LDAP module, and some other CPAN code I’ve seen, no check is done to see if an unexpected key is defined. The justification for this is the possible use of inheritance. If you pass a “foo” parameter to an object, it may not know what to do with “foo” but one of the other methods inherited by that object may. That’s why you’ll see things like…
my($self, %opts) = @_;
and then later…
$self->someOtherMethod($this, $that, %opts);
As for my own code, I’m still working on coming up with a good way to used named parameters with methods where all of the methods that get a set of named parameters have to ‘claim’ the ones that that particular method is using, so that in the end, if there are any unclaimed named parameters, an exception is thrown. Haven’t come with what I think is a clean solution, but I’m still thinking about it.
I hope this is the sort of thing Moose fixes.