Bug #85494 for Getopt-Modular: Enhancement request for version 0.10

Tue May 21 13:04:57 2013 jeff.holt [...] method-r.com - Ticket created

Subject:	Enhancement request for version 0.10
Date:	Tue, 21 May 2013 12:04:42 -0500
To:	bug-Getopt-Modular [...] rt.cpan.org
From:	Jeff Holt <jeff.holt [...] method-r.com>

Hi Darin. Can you please add a getOpts method to Modular.pm so that a user migrating from Getopt::Long to Getopt::Modular has to modify only a couple of lines? Presently, such a user would have to modify every line that makes an option reference. Here's the code: sub getOpts { my $self = _self_or_global(\@_); my %opts; for (keys %{$self->{accept_opts}}) { $opts{$_} = $self->getOpt($_); } return %opts; } You could also do the perly thing and modify getOpt method to return $self->getOpts() when it's not given an argument. I tried testing it and noticed that there's no test for when getOpt is not given a value. I was expecting (but didn't get) at least one test to fail when I modified line 2 of getOpt to this: my $opt = shift; return $self->getOpts() unless defined $opt; So, I guess that since there's no such test, then it's safe to make that change too. And if you were to make such a change, then there'd be no need to publish getOpts.

Tue May 21 15:48:53 2013 dmcbride [...] cpan.org - Correspondence added

On Tue May 21 13:04:57 2013, jeff.holt@method-r.com wrote: Show quoted text

> Hi Darin. > > Can you please add a getOpts method to Modular.pm so that a user migrating > from Getopt::Long to Getopt::Modular has to modify only a couple of lines? > Presently, such a user would have to modify every line that makes an option > reference.

As I'm looking at this, what stands out to me as an option is to allow parseArgs to take an optional hash ref, much as GetOptions does. GM->parseArgs(\%opts); If you're migrating from Getopt::Long, this should be about equivalent to the existing GetOptions call, giving the %opts hash pretty much the same existing scope. If that parameter is given, then it will get populated much as you suggested, which, unfortunately, will force-fill all parameters, even ones that aren't otherwise needed. (Methods for making these values lazy-fill are probably not worth the effort.) For most people, most of the time, this is fine, but I have had defaults filled in by expensive network operations, so avoiding that for runs that don't need them was worthwhile. So, what do you think? I think this is substantially similar to your suggestion, and might involve less change for the migrating user. I'd also like to add that missing getopt-missing-a-parameter test :) And, for that matter, most of the exceptions.

Tue May 21 15:48:53 2013 The RT System itself - Status changed from 'new' to 'open'

Tue May 21 16:10:59 2013 jeff.holt [...] method-r.com - Correspondence added

Subject:	Re: [rt.cpan.org #85494] Enhancement request for version 0.10
Date:	Tue, 21 May 2013 15:10:39 -0500
To:	bug-Getopt-Modular [...] rt.cpan.org
From:	Jeff Holt <jeff.holt [...] method-r.com>

I dont' see how that would accomplish the goal of "not having to change all the %opt r-values in the user's code. Given this code: use Getopt::Long; my %opt = (ask=>0); GetOptions("ask!"=>\$opt{ask}) or die; printf "$opt{ask}\n"; can you show me what it would look after it's transformed using your suggestion? If I'm just not seeing the obvious, then I'm sorry. Generally speaking, anything suggestion that accomplishes the goal is acceptable. After making the changes I described to Modular.pm 0.10, this is my transformation: use Getopt::Modular; Getopt::Modular->acceptParam( ask => { default => 0, spec => "!", help => "Ask the user to reply." } ); Getopt::Modular->parseArgs(); my %opt = Getopt::Modular->getOpts(); printf "$opt{ask}\n"; On Tue, May 21, 2013 at 2:48 PM, Darin McBride via RT < bug-Getopt-Modular@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=85494 > > > On Tue May 21 13:04:57 2013, jeff.holt@method-r.com wrote:

> > Hi Darin. > > > > Can you please add a getOpts method to Modular.pm so that a user

> migrating

> > from Getopt::Long to Getopt::Modular has to modify only a couple of

> lines?

> > Presently, such a user would have to modify every line that makes an

> option

> > reference.

> > As I'm looking at this, what stands out to me as an option is to allow > parseArgs to take an optional hash ref, much as GetOptions does. > > GM->parseArgs(\%opts); > > If you're migrating from Getopt::Long, this should be about equivalent to > the existing GetOptions call, giving the %opts hash pretty much the same > existing scope. > > If that parameter is given, then it will get populated much as you > suggested, which, unfortunately, will force-fill all parameters, even ones > that aren't otherwise needed. (Methods for making these values lazy-fill > are probably not worth the effort.) For most people, most of the time, > this is fine, but I have had defaults filled in by expensive network > operations, so avoiding that for runs that don't need them was worthwhile. > > So, what do you think? I think this is substantially similar to your > suggestion, and might involve less change for the migrating user. > > I'd also like to add that missing getopt-missing-a-parameter test :) And, > for that matter, most of the exceptions. >

Tue May 21 16:50:14 2013 darin.mcbride [...] shaw.ca - Correspondence added

Subject:	Re: [rt.cpan.org #85494] Enhancement request for version 0.10
Date:	Tue, 21 May 2013 14:49:58 -0600
To:	bug-Getopt-Modular [...] rt.cpan.org
From:	Darin McBride <darin.mcbride [...] shaw.ca>

On Tuesday May 21 2013 4:11:00 PM you wrote: Show quoted text

> Queue: Getopt-Modular > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85494 > > > I dont' see how that would accomplish the goal of "not having to change all > the %opt r-values in the user's code. Given this code:

Maybe, then, I'm not understanding your usage :) Show quoted text

> use Getopt::Long; > my %opt = (ask=>0); > GetOptions("ask!"=>\$opt{ask}) or die; > printf "$opt{ask}\n"; > > can you show me what it would look after it's transformed using your > suggestion? If I'm just not seeing the obvious, then I'm sorry. Generally > speaking, anything suggestion that accomplishes the goal is acceptable.

Show quoted text

> After making the changes I described to Modular.pm 0.10, this is my > transformation: > > use Getopt::Modular; > Getopt::Modular->acceptParam( > ask => { default => 0, spec => "!", help => "Ask the user to reply." } > ); > Getopt::Modular->parseArgs(); > my %opt = Getopt::Modular->getOpts(); > printf "$opt{ask}\n";

Ok, this is what I was thinking: use Getopt::Modular; Getopt::Modular->acceptParam( ask => { default => 0, spec => "!", help => "Ask the user to reply." } ); my %opt; Getopt::Modular->parseArgs(\%opt); printf "$opt{ask}\n"; This is longer than the original Getopt::Long, but I consider that to be a Feature(TM) :) However, passing in the \%opt into parseArgs is analogous to passing it in to GetOptions. Mind you, normally I call GetOptions like this: GetOptions(\%opt, 'ask!', ...) or die; which makes passing in the hash to parseArg even more similar. I also found out that this might work as well - replacing the third- and second-last lines above with this one: Getopt::Modular->parseArgs(\my %opt); which compresses it a bit more. While I use this all the time for open, I don't do this very often with anything else...

Tue May 21 16:52:00 2013 jeff.holt [...] method-r.com - Correspondence added

Subject:	Re: [rt.cpan.org #85494] Enhancement request for version 0.10
Date:	Tue, 21 May 2013 15:51:40 -0500
To:	bug-Getopt-Modular [...] rt.cpan.org
From:	Jeff Holt <jeff.holt [...] method-r.com>

Yes, that's more than adequate. On Tue, May 21, 2013 at 3:50 PM, Darin McBride via RT < bug-Getopt-Modular@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=85494 > > > On Tuesday May 21 2013 4:11:00 PM you wrote:

> > Queue: Getopt-Modular > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85494 > > > > > I dont' see how that would accomplish the goal of "not having to change

> all

> > the %opt r-values in the user's code. Given this code:

> > Maybe, then, I'm not understanding your usage :) >

> > use Getopt::Long; > > my %opt = (ask=>0); > > GetOptions("ask!"=>\$opt{ask}) or die; > > printf "$opt{ask}\n"; > > > > can you show me what it would look after it's transformed using your > > suggestion? If I'm just not seeing the obvious, then I'm sorry. Generally > > speaking, anything suggestion that accomplishes the goal is acceptable.

>

> > After making the changes I described to Modular.pm 0.10, this is my > > transformation: > > > > use Getopt::Modular; > > Getopt::Modular->acceptParam( > > ask => { default => 0, spec => "!", help => "Ask the user to reply."

> }

> > ); > > Getopt::Modular->parseArgs(); > > my %opt = Getopt::Modular->getOpts(); > > printf "$opt{ask}\n";

> > Ok, this is what I was thinking: > > use Getopt::Modular; > Getopt::Modular->acceptParam( > ask => { default => 0, spec => "!", help => "Ask the user to reply." } > ); > my %opt; > Getopt::Modular->parseArgs(\%opt); > printf "$opt{ask}\n"; > > This is longer than the original Getopt::Long, but I consider that to be a > Feature(TM) :) However, passing in the \%opt into parseArgs is analogous > to > passing it in to GetOptions. Mind you, normally I call GetOptions like > this: > > GetOptions(\%opt, 'ask!', ...) or die; > > which makes passing in the hash to parseArg even more similar. > > I also found out that this might work as well - replacing the third- and > second-last lines above with this one: > > Getopt::Modular->parseArgs(\my %opt); > > which compresses it a bit more. While I use this all the time for open, I > don't do this very often with anything else... > >

Sat May 25 10:20:06 2013 dmcbride [...] cpan.org - TimeWorked changed from (no value) to '180'

Sat May 25 10:20:07 2013 dmcbride [...] cpan.org - Status changed from 'open' to 'resolved'

Sat May 25 10:20:07 2013 dmcbride [...] cpan.org - Taken