RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
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 enough. local @[EMAIL PROTECTED]; Goes a long way you know. Yves
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
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 object method in OO mode or through functions, for a list of recognized options their types (e.g., whether int, bool, string or no arg; their linkage, etc.) and Im confused why the obvious solution to the second is not good enough. local @[EMAIL PROTECTED]; Goes a long way you know. 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. Mx.
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
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 every function that may use them? [1] Global things are intended to be global, I'd say. -- Johan [1] This reminds me of an anecdote while I was at the University. We were taught programming, and the rules were quite strict. No globals, only formal parameters. They even dictated the exact parameter list. Files were not part of the parameters. So when I pointed out that a particular routine that needed to produce output could not access the file they decided that the file should be kept local to the routine. Now that was fun, since opening and closing a file caused the printing system to print a couple of banner pages. When my program completed, I had a big pile of output, instead of just a couple of pages. They quickly changed the rules after that :-).
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
* 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
filehandle-specific globals in Perl 6?
I don’t see how being able to *optionally* say something like
GetOptions(
[EMAIL PROTECTED],
# ...
);
would detract from anything at all. All it takes to implement in
GetOptions() are about two lines of code. (With current calling
conventions; I did look.)
* Johan Vromans [EMAIL PROTECTED] [2005-06-20 14:35]:
You mean, you are going to pass things like STDOUT, STDERR, ENV
and so on, to every function that may use them? [1]
Yeah, and
chomp $foo
is wasteful – we should teach people to just say
do { local *_ = \$foo; chomp; }
Hmm, but where the heck does that strange “select FH” fit in
anywhere?
:-)
I think it’s a good default for GetOptions to process @ARGV.
Noone will dispute that. I also think it would be a good thing to
be able to explicitly pass a different array instead. I can’t see
why anyone would dispute that.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
# 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 to pass a different array to
GetOptions(). After all, that really is just meant for parsing
command-line arguments, which aren't going to be found anywhere besides
@ARGV.
What I do think you need is a way to pass a different array to
*something*, so that wrapping and reusing is easier:
Consider how things change if GetOptions were structured something like
the following instead of having all of that tasty parsing logic stuck
inside of it.
sub GetOptions {
my $self = Getopt::Modern-create(@_);
return($self-get([EMAIL PROTECTED]));
}
Now, if you wanted to write a wrapper (or even an api function (ala Tk)
that took a mixed list of arguments and options), you would just call
$opt-get([EMAIL PROTECTED]) instead of GetOptions().
To me, it mostly comes down to thinking what the heck does ARGV have to
do with anything? everytime I see 'local @ARGV = @arglist'.
--Eric
--
I arise in the morning torn between a desire to improve the world and a
desire to enjoy the world. This makes it hard to plan the day.
--E.B. White
-
http://scratchcomputing.com
-
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
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 detract from anything at all. I don't think you really need to be able to pass a different array to GetOptions(). After all, that really is just meant for parsing command-line arguments, which aren't going to be found anywhere besides @ARGV. Well, that's a strong assumption. Perl::Tidy, for instance, uses Getopt::Long to parse its parameter list, which has nothing to do with @ARGV. And see http://rt.cpan.org/NoAuth/Bug.html?id=7964 for the kind of trouble that happens when a library uses another library that has a global configuration. In that case, local @ARGV = @whatever is not enough. -- Philippe BooK Bruhat The best thing about being apart is getting together again. (Moral from Groo The Wanderer #39 (Epic))
