# 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
> 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
# 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,
>> GetOptionsWith
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 code
[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,
# 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?)
--Eri
* 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]:
> G
[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 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 firs
Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
[EMAIL PROTECTED] wrote on Monday, June 27, 2005 11:46 AM
> [Quoting Orton, Yves, on June 27 2005, 10:17, in "RE:
> Getopt::Long wis"]
> > sub GetOptions {
> > GetOptionsArray([EMAIL PROTECTED],@_);
&g
[Quoting Orton, Yves, on June 27 2005, 10:17, in "RE: Getopt::Long wis"]
> sub GetOptions {
> GetOptionsArray([EMAIL PROTECTED],@_);
> }
GetOptionsFromArray?
-- Johan
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 "i
[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 usin
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.
Th
# The following was supposedly scribed by
# Philippe 'BooK' Bruhat
# on Monday 20 June 2005 09:35 am:
>> 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 foun
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],
> > # ...
> >
# 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
* 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
"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
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, eithe
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
On Fri, Jun 17, 2005 at 05:48:21PM +0200, A. Pagaltzis wrote:
> * Johan Vromans <[EMAIL PROTECTED]> [2005-06-17 17:20]:
> > I can make this information available, if users would be
> > interested.
>
> Access to structured data is always nicer than implementing and
> re-implemeting a parser for its
22 matches
Mail list logo
