To Eric,
Some might-be-helpful thoughts for you:
1. Bundling Problem on Getopt::Long:
Yes, I was very troubled for that problem before. I even had a same
thought as you to parse the arguments by myself. But after a couple of
tries I gave up. My codes get all messed up. Then I found my life could
be easier with Getopt::Long. Now I have neat codes. Bundling problem?
I never document the use of bundled options. It's OK if they hack and
try that. But I'm not their mon. For me, controlling them for their
possibility is non-sense. They take their own responsibility for its
behavior. They can hack, and they can have fun.
You may not agree with me. That's fine. Bundling problem is rather
complicated. It's a challenge to anyone. I won't get jealous if you
solved it and I couldn't. ^_^
2. The "--no-fish" or "--un-fish" Issue:
Actually, if I were you, I would use "--no-default-fish", or
"--no-def-fish". With
go_shop --fish tuna --fish halibut --no-default-fish
go_shop --no-default-fish --fish tuna --fish halibut
it makes perfect sense that these commands should get the same
result. It reads naturally.
3. The 2 Lines Example:
Actually, I can deduce it into one. The use of the $opt_nofish
variable is non-sense.
Getopt::Long::GetOptions(
"fish=s" => [EMAIL PROTECTED],
"no-default-fish" => sub { @conf_fishes = qw() },
);
@fishes = (@conf_fishes, @opt_fishes);
As I said, you can work in a more flexible way on this issue. You
might originally be tied to the impression of:
Getopt::Long::GetOptions(
"verbose!" => \$verbose,
);
which may only be one convienent usage of Getopt::Long.
--
Best regards,
imacat ^_*' <[EMAIL PROTECTED]>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt
<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug
pgpH7Ryuq5AcL.pgp
Description: PGP signature
