Yes, I dislike non-named optional arguments to functions ... especially when there's more than one! Much prefer to handle optional arguments via a single hashref argument because I feel this scales better over time - to support a new optional argument simply support a new key value in the hash with a sensible default and old code keeps on working without modification.
This is especially important in functions taking more than three parameters because humans are better at remembering names than orderings - as indicated by the Perl Best Practices guideline "Use a hash of named arguments for any subroutine that has more than three parameters". BTW, as indicated at Named Subroutine Parameters: Compile-time errors vs. Run-time warnings, the "reason" given for a hash reference (rather than a hash) was an error in the book: anonymous hash population is done at run-time, not compile-time; that said, Conway still stands by this advice because "Error messages that point users to the right place are definitely worth the (tiny) overhead of passing named args in a hash".
An example of a Perl internal function with a poor interface is split, which has two (update:three) optional arguments and much surprising magic such as ' ' vs / / vs // vs /^/ as the first argument; empty leading fields preserved, empty trailing fields stripped by default; negative LIMITs; and many more. I feel split would have been much clearer and more manageable over time, if instead of using optional arguments (and special magic values for parameters) it had used a single named hashref argument to specify tricky behaviour.
In reply to Re^2: More comprehensive style guide for Perl docs than perlpodstyle?
by eyepopslikeamosquito
in thread More comprehensive style guide for Perl docs than perlpodstyle?
by nysus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |