[EMAIL PROTECTED] (Johan Vromans) writes: > [Quoting Sam Vilain, on June 27 2005, 22:56, in "Re: Getopt::Long wis"] >> If passing an array ref first doesn't interfere with the calling >> convention, then imho you don't need to change the function name. > > Interfere? No, but elegant? > Currently, GetOptions allows an array ref as the first argument (to > fetch the options from), but it also allows a hash ref as the first > argument (to store the options in), while the first argument may also > be something typical non-option to designate a different option > starter string. For the programmer, there's a very definite order in > these 'first' arguments, but I doubt the ordinary (or casual) user > will find this easy.
Despite this, I now strongly lean towards _not_ creating an additional entry point for this functionality. While GetOptionsFromArray seems nice, there's also a reason for GetOptionsToHash, GetOptionsWithNonStandardIntroducer and so on. This would make code and maintenance unneccessarily complex. So my proposal: * Entry point remains GetOptions * First argument may be an array ref -> array to parse options from * First (or next) argument may be a hash ref -> hash to put option values in * First (or next) argument, if scalar and not a valid option, may introduce non-standard option introducers. -- Johan
