I don't like package methods since I can't import them.

I can simply import
Getopt::Long::Framework::getOpt
with
*getOpt = \&Getopt::Long::Framework::getOpt
(or even more simply through use)

But to import
Getopt::Long::Framework->getOpt
I need to create the wrapper
sub getOpt { Getopt::Long::Framework->getOpt(@_) }

You suggest using inheritance (use base ...), but I hate inherting where there isn't an is-a relationship.

It doesn't seem to be needed here. If I understand correctly, you want to allow multiple modules to specify options they accept. Wouldn't the following be sufficient?

# Module1
Getopt::Long::Framework::accept(...);
.
:
# Module2
Getopt::Long::Framework::accept(...);
.
:
# Module3
Getopt::Long::Framework::accept(...);
.
:
# First call to getOpt processes @ARGV.
$val = Getopt::Long::Framework::getOpt(...);
[download]

# Module1
use Getopt::Long::Framework accept => ...;
.
:
# Module2
use Getopt::Long::Framework accept => ...;
.
:
# Module3
use Getopt::Long::Framework accept => ...;
.
:
# First call to getOpt processes @ARGV.
$val = Getopt::Long::Framework::getOpt(...);
[download]

And this is one of the reasons why I asked. Sometimes I latch on to a single design viewpoint, and then I have no one to knock sense into me ;-)

What I am trying to figure out is how the user will be able to override things this way. For example, if I factor out a function that "gets" the order of the parameters to be parsed, how does the user override that to reorder them? Or, more likely, some of the usage functions. With package methods, this is easy - we can re-use the built-in perl functions for doing so by simply capturing the first parameter and using it for dispatching to the next section. my $class = shift; ... $class->display_help(...) Otherwise, I need to maintain a bunch of code refs and figure out the right one to call, and then SUPER won't work as expected, either, so I need to pass in the original code ref in case you just want to modify existing behaviour. e.g., sub option_list { my $super = shift; my @o = $super->option_list();  sort \&some_funky_sort @o; } which is pretty ugly, too. If I don't provide for it, whether that be a singleton or a package or maintaining a bunch of extra coderefs, you won't be able to override things.

I suppose the other question is - will anyone really need to override anything? Perhaps not. Am I just overdesigning? It's hard for me to tell. Afterall, I wrote the original methods the way I wanted them to be, and maybe that's good enough for others. I may have a lot of Hubris, but not that much - so I assume people will want to tweak things, but without modifying my module.

You both appear to have overlooked the very simple alternative:

my $p= 'Getopt::Long::Framework';

$p->What();
$p->Ever();
[download]

But I don't buy the 'singleton' concept in general. Even CGI.pm realizes that sometimes There Can Be More Than One, even for things where that is almost never wanted and it is easy to fail to see any cases when someone would want Two.

Implement your functionality using plain (non-singleton) objects and just provide a handy shortcut for getting the default, global instance. Then you have the benefits of 'singleton' without the limitations.

- tye        

I thought of that $p part, too, just forgot to mention it. I'm not sure, though, that this would be better-received. ;-)

As for your non-singleton approach - something like this?

my $default;

sub new
{
  my $class = shift || __PACKAGE__;
  my $self = {};
  bless $self, $class;
  $default ||= $self;
}

sub global_instance
{
  $default ||= (shift || __PACKAGE__)->new();
}
[download]

And, perhaps, a way to change the global instance to be another one, if you really do need More Than One?

"App-Options combines command-line arguments, environment variables, option files, and program defaults..."

Other interesting possibilities:

• Config-Easy
• AppConfig
• Getopt-ArgvFile
• Config-Frontend in conjunction with Config-Backend-File, Config::Backend::String, etc.

Of these, the one I think holds the most promise is the last, because it was clearly designed with extensibility in mind. Config-Frontend doesn't seem to come with a backend for reading the command line, but one could easily be written.

Background

I went scrounging around CPAN for modules that would support simple, flexible application configuration management. Here's what I came up with.

First, there are modules which simply read/write certain config file formats:

• Config-Trivial
• Config-IniFiles
• Config-Tiny
• Config-General
• Config-IniHash
• ConfigReader-Simple
• Config-Objective
• Config-Natural

There are modules which try to be config file polyglots:

• Config-Auto

There's a handful of modules that try to tackle the problem of locating config files:

• Config-Auto
• Config-Find
• Config-IniSearch

Then there are modules that try to handle more sources of config info than just files, e.g. integrating command-line options with configfile data.

Those are the ones I listed in my reply, above.

PS - I'm not trying to downplay the power of any of these modules. I realize that some of them do a lot more than what I've characterized here. I'm just focusing on the types of data sources supported.

PPS - If you know of a module not listed here that you think ought to be, please /msg me first, rather than reply. Thanks.

Obviously, a program has but one @ARGV.
Thus, the data will be global.

sub func {
  local @ARGV = @_;
  my( @foo, @bar );
  GetOptions(
    'foo=s' => \@foo,
    'bar=s' => \@bar,
  );
  print "foo = @foo\nbar = @bar\n";
}

func( -foo => 1, -bar => 1, -foo => 2, -bar => 2 );
[download]

:-)

You mostly have a point. Getopt::Long is simple enough for that scenario where everything pretty much lives inside a single function. This framework is targetted at more complex interaction where acceptable options come from multiple locations.

I can imagine that some functions may find this useful, but I am having a hard time imagining what functions those may be ;-)