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.
# The following was supposedly scribed by
# Johan Vromans
# on Saturday 09 July 2005 02:58 am:
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.
I'm puzzled. Basically, you suggest that it is
[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,
On Jul 5, 2005, at 4:44 AM, Johan Vromans wrote:
... 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
[Quoting Sam Vilain, on June 27 2005, 11:35, in Re: Getopt::Long wis]
Johan Vromans wrote:
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.
This is why code using CGI.pm
Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
[EMAIL PROTECTED] wrote on Monday, June 27, 2005 9:46 AM
Anyway, the next version of Getopt::Long will have the ability to use
an arbitrary array instead of ARGV.
Now, do you want this to be yet another if the first argument
[Quoting Orton, Yves, on June 27 2005, 10:17, in RE: Getopt::Long wis]
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
GetOptionsFromArray?
-- Johan
Orton, Yves wrote:
Imo it would better to expose a different subroutine name for this.
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Is that ruled out for some reason?
If you consider the signature a part of the subroutine name, then
simply making it take an arrayref as the first
[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
* Orton, Yves [EMAIL PROTECTED] [2005-06-27 11:25]:
Imo it would better to expose a different subroutine name for this.
Ie:
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Sounds like a very good idea to me.
* Johan Vromans [EMAIL PROTECTED] [2005-06-27 11:55]:
# The following was supposedly scribed by
# Johan Vromans
# on Monday 27 June 2005 02:46 am:
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
GetOptionsFromArray?
That sounds like a great idea.
Any chance of it involving an object (and therefore multi-pass support?)
--Eric
--
Johan Vromans wrote:
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.
This is why code using CGI.pm is so hard to wrap, too. Assumptions that
globals will always be globals.
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
18 matches
Mail list logo
