Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-11 Thread Bob Rogers
From: Uri Guttman [EMAIL PROTECTED] Date: Fri, 10 Sep 2004 01:37:14 -0400 BR == Bob Rogers [EMAIL PROTECTED] writes: BRBut this morning, I had an idea for Pod::CLOD while showering. BR (That's a good sign; some of my best ideas come to me in the shower.) so you aren't

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-11 Thread Bob Rogers
From: Greg London [EMAIL PROTECTED] Date: Thu, 9 Sep 2004 23:00:24 -0400 (EDT) Bob Rogers said: Seriously, splitting up the options this way does make it easier to combine them, but it still requires globals to store the values, and as long as that's true, I find it hard

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-11 Thread Uri Guttman
BR == Bob Rogers [EMAIL PROTECTED] writes: BRThe Parse sub is a prime example of what I would consider BR counterproductive code decoration. It violates the first rule of BR commenting, namely that comments should say something about the code BR that is not obvious: as i said, i am

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-09 Thread David Cantrell
On Wed, Sep 08, 2004 at 11:41:55PM -0400, Bob Rogers wrote: Uri Guttman [EMAIL PROTECTED] supershited: use strict; use warnings should be here too. Thank you; that sounds like a good idea. (Though usually my main interest in manipulating perl warnings is shutting them up in production

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-09 Thread Greg London
Bob Rogers wrote: I think I'm already well past that point in terms of option-parsing complexity. I have places where the command_line_options method calls SUPER::command_line_options in order to replace/rename options, so I need some way to supercede and/or rename things. got it. I had to

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-09 Thread Greg London
Greg London wrote: Bob Rogers wrote: I have places where the command_line_options method calls SUPER::command_line_options in order to replace/rename options, so I need some way to supercede and/or rename things. Hey, just a random thought, but rather than building up a simple string in

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-09 Thread Bob Rogers
From: David Cantrell [EMAIL PROTECTED] Date: Thu, 9 Sep 2004 11:11:29 +0100 On Wed, Sep 08, 2004 at 11:41:55PM -0400, Bob Rogers wrote: Uri Guttman [EMAIL PROTECTED] supershited: use strict; use warnings should be here too. Thank you; that sounds like a good idea.

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-09 Thread Bob Rogers
From: Greg London [EMAIL PROTECTED] Date: Thu, 09 Sep 2004 09:43:38 -0400 . . . A quick email to Damian with your rule search/replace/rename question might get you a quick answer. who knows, Damian might be able to tweak it while he's on a long flight somewhere. If you

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-09 Thread Uri Guttman
BR == Bob Rogers [EMAIL PROTECTED] writes: BR problem. In particular, I have had to use BR no warnings 'recursion'; BR on occasion because the implementers of perl thought it sufficiently BR abnormal to be worth a warning if a particular function is ever entered BR 100 times more

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-08 Thread Aaron Sherman
On Wed, 2004-09-08 at 00:17, Uri Guttman wrote: use warnings should be here too. [...] i like _$method better. [...] i don't like using = like that. Uri, you're ripping the guy's code to shreds over minor points of syntactic sugar... I seem to remember that Perl's moto isn't There's only one

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-08 Thread Sean Quinlan
On Wed, 2004-09-08 at 10:34, Aaron Sherman wrote: On Wed, 2004-09-08 at 00:17, Uri Guttman wrote: use warnings should be here too. [...] i like _$method better. [...] i don't like using = like that. Uri, you're ripping the guy's code to shreds over minor points of syntactic sugar...

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-08 Thread Greg London
Bob Rogers said: easier to add command-line options through class inheritance and reuse than it is to document them. I have attached an early version of the Hm, I've been using Getopt::Declare for a lot of command-line scripts at work. I'm not a webhead, I do command line tools, so command

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-08 Thread Uri Guttman
SQ == Sean Quinlan [EMAIL PROTECTED] writes: SQ On Wed, 2004-09-08 at 10:34, Aaron Sherman wrote: On Wed, 2004-09-08 at 00:17, Uri Guttman wrote: use warnings should be here too. [...] i like _$method better. [...] i don't like using = like that. Uri, you're

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-08 Thread Chris Devers
On Wed, 8 Sep 2004, Uri Guttman wrote: SQ == Sean Quinlan [EMAIL PROTECTED] writes: SQ While making recommendations on style can be useful, particularly SQ in the cases where it can reduce the possibility of bugs, I would SQ agree that approaching the main request of the poster first might SQ

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-08 Thread Bob Rogers
From: Sean Quinlan [EMAIL PROTECTED] Date: Wed, 08 Sep 2004 11:25:07 -0400 Although I haven't personally come across the need to have multiple scripts have re-used command line options yet (other than a few old historic cases), this sounds like an interesting project for handling

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-08 Thread Bob Rogers
From: Uri Guttman [EMAIL PROTECTED] Date: Wed, 08 Sep 2004 00:17:15 -0400 BR == Bob Rogers [EMAIL PROTECTED] writes: BR use strict; use warnings should be here too. Thank you; that sounds like a good idea. (Though usually my main interest in manipulating perl warnings is

Re: [Boston.pm] Inheriting documentation for inherited command-line options

2004-09-08 Thread Uri Guttman
BR == Bob Rogers [EMAIL PROTECTED] writes: BR sub BEGIN { BR no strict 'refs'; BR for my $method (qw(option_definers additional_options BR man_p help_p usage_p)) { BR my $field = '_' . $method; BRi like _$method better. BR I don't; it's harder to see. i find . hard to see