Re: Getopt::Long wishes (was: RFC: Getopt::Modern)

2005-06-27 Thread Eric Wilhelm 
# 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
-- 
Atavism  n:  The recurrence of any peculiarity or disease of an ancestor
in a subsequent generation, usually due to genetic recombination.
-
http://scratchcomputing.com
-

Re: Getopt::Long wishes (was: RFC: Getopt::Modern)

2005-06-27 Thread A. Pagaltzis 
* 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]:
> GetOptionsFromArray?

I like that name.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;

Re: Getopt::Long wishes (was: RFC: Getopt::Modern)

2005-06-27 Thread Johan Vromans 
[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 (to
fetch the options from), but it also allows a hash ref as the first
argument (to store the options in), while the first argument may also
be something typical non-option to designate a different option
starter string. For the programmer, there's a very definite order in
these 'first' arguments, but I doubt the ordinary (or casual) user
will find this easy.

-- Johan

Re: Getopt::Long wishes (was: RFC: Getopt::Modern)

2005-06-27 Thread Sam Vilain 

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 argument is enough
to distinguish it.

in Perl 6 you could say

  multi sub GetOptions(Array @ARGV, Pair [EMAIL PROTECTED]) { ... }

is a different subroutine to

  multi sub GetOptions(Pair [EMAIL PROTECTED]) { ... }

If passing an array ref first doesn't interfere with the calling
convention, then imho you don't need to change the function name.

But that, of course, is a matter of style ;-)

Sam.

RE: Getopt::Long wishes (was: RFC: Getopt::Modern)

2005-06-27 Thread Orton, Yves 
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],@_);
> > }
> 
> GetOptionsFromArray?
>


Yeah, IMO that would be fine.


yves

Re: Getopt::Long wishes (was: RFC: Getopt::Modern)

2005-06-27 Thread Johan Vromans 
[Quoting Orton, Yves, on June 27 2005, 10:17, in "RE: Getopt::Long wis"]
> sub GetOptions {
>   GetOptionsArray([EMAIL PROTECTED],@_);
> }

GetOptionsFromArray?

-- Johan

RE: Getopt::Long wishes (was: RFC: Getopt::Modern)

2005-06-27 Thread Orton, Yves 
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 is an
> array reference ..." or yet another :config option?
>


Imo it would better to expose a different subroutine name for this.


Ie:


sub GetOptions {
  GetOptionsArray([EMAIL PROTECTED],@_);
}


Is that ruled out for some reason?


Yves

Re: Getopt::Long wishes (was: RFC: Getopt::Modern)

2005-06-27 Thread Johan Vromans 
[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 is so hard to wrap, too.  Assumptions that
> globals will always be globals.
> 
> Then you go and try and do anything vaguely re-entrant and it all falls
> to pieces.

I think there's a fundamental difference between user variables that
are used globally (which, indeed, expose the problem you mentioned)
and variables that are global by design, like STDOUT and ARGV.

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 is an
array reference ..." or yet another :config option?

-- Johan