Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
-) Structured access to the option settings
-) Option to pass in something other @ARGV to the
arg-processing code.
Id be curious what you mean by the first, and Im confused why the obvious solution to the second is not good
Greetings,
On Mon, Jun 20, 2005 at 11:06:49AM +0100, Orton, Yves wrote:
-) Structured access to the option settings
-) Option to pass in something other @ARGV to the
arg-processing code.
Id be curious what you mean by the first,
I mean the ability to query Getopt::Long, either by an
Martyn J. Pearce [EMAIL PROTECTED] writes:
It does, and it works, and it is a stylistic thing perhaps, but although
global variables can be made to work, the modern phenomenon of function
arguments are very popular.
You mean, you are going to pass things like STDOUT, STDERR, ENV and so
on, to
* Orton, Yves [EMAIL PROTECTED] [2005-06-20 12:15]:
Im confused why the obvious solution to the second is not good
enough.
local @[EMAIL PROTECTED];
Goes a long way you know.
I don’t like that at all, myself. It works, sure, but then so
does “local $/”, and guess what’s happening to all
# The following was supposedly scribed by
# A. Pagaltzis
# on Monday 20 June 2005 08:57 am:
I don’t see how being able to *optionally* say something like
GetOptions(
[EMAIL PROTECTED],
# ...
);
would detract from anything at all.
I don't think you really need to be able
Le lundi 20 juin 2005 à 09:09, Eric Wilhelm écrivait:
# The following was supposedly scribed by
# A. Pagaltzis
# on Monday 20 June 2005 08:57 am:
I don???t see how being able to *optionally* say something like
GetOptions(
[EMAIL PROTECTED],
# ...
);
would