# The following was supposedly scribed by
# Ken Williams
# on Tuesday 05 July 2005 11:13 am:
>> ... 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.
>
>You could easily add a method that accepted named parameters instead
> of positional (which IMO would improve readability a lot):
>
>GetOptions(from => [EMAIL PROTECTED],
> described_by => ["length=i", file=s", "verbose"],
> to => \%args,
> ...);
>
>IMO that's usually the right way to make the interface when there are
>lots of different orthogonal options that the caller might want to
>employ.
Wouldn't that mostly kill reverse-compatibility?
I don't like the idea of more positional parameters or multiple entry
points. As I've said before, if GetOptions() could be a few-lines
wrapper around the $opt = Getopt::Long->new()... $opt->get([EMAIL PROTECTED])
dance, this allows the author (of what will most likely be a module if
they want to parse something besides ARGV) to design their own entry
point if need be. Ok, it's going to be more than a few lines by the
time you get all of the reverse compatibilities in, but the general
idea is clean.
Remember, to be reverse compatible, all you have to do is put the
interface to the existing functionality back where you found it.
There's not a lot of reason to add new functionality into the old
interface because anybody using the new functionality (by definition)
requires the new version.
--Eric
--
The opinions expressed in this e-mail were randomly generated by
the computer and do not necessarily reflect the views of its owner.
--Management
---------------------------------------------
http://scratchcomputing.com
---------------------------------------------
