In a recent thread, I opined that I would try to CPAN-ise my wrapper around Getopt::Long. This is largely because this was the second time where I saw someone trying to reinvent this wheel - and, from experience, once you start making this wheel, it can grow to be quite large, yet very easy to use.

Obviously, a program has but one @ARGV set of command line options. (Well, except for the tests - that will be another kettle of fish to deal with.) Thus, the data will be global. The way I currently do that is to hide a singleton in the package, and do it OO-ish. From using this for the last 4 or 5 years, I'm not sure that's really necessary, so I'm thinking that while I'm at it, I can just change the way that it stores this global data.

For now, I'm working with a name of 'Getopt::Long::Framework' which is a bit long, but is the most descriptive I've come up with so far. (Better ideas are more than welcome.) I'm also using all the functions as package methods - disadvantage is that you may be typing 'Getopt::Long::Framework->...' all the time. Advantage is that you can create your own package, say 'GLF' which just does a "use base 'Getopt::Long::Framework'" and then will be able to override some functions, and even be able to set up with a default list of parameters (e.g., --debug) that may be applicable to your project.

Note: this is not intended for one-liners or other small scripts. This is more intended for a large framework of related applications that reuse each others' modules, and will allow you to build up the option list on the fly.

The question I'm wondering about is how you would approach this? Are package methods a "good" way to do this? Will I put off potential users?

FYI: the synopsis (thus far): 

  use Getopt::Long::Framework;

  Getopt::Long::Framework->accept(
    'qwib=i' => {
      default => 30,
      validate => qr/^(?:\d|\d\d)$/,
      help => 'sets up the qwibble factor',
    },
    'blah|b=s' => {
      default => sub { $ENV{blah} || 'frobnicate' },
      validate => sub { -d $_ },
      help => 'sets the frobnicator directory',
    },
  );

  my $frob_dir = Getopt::Long::Framework->getOpt('blah');

[download]
An alternative is to export functions into the caller's space, but that probably would be much more difficult to manage how to override things in a central location.

Update: strike-out/italics based on jdporter's comments below.

In reply to Design of a global-variable storage package by Tanktalus

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.