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.

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?

Rather than try to detect, I'd probably do something deterministic like export functions that use the singleton:

package Getopt::Long::Framework;
use vars qw( @EXPORT_OK );
@EXPORT_OK= qw( Foo Bar Baz );

require Getopt::Long::Framework::Object;

my $singleton = Getopt::Long::Framework::Object->new();

sub Foo
{
    $singleton->Foo( @_ );
}

...

sub GetObjectPackage
{
    "Getopt::Long::Framework::Object";
}

sub new
{
    my $class= shift @_;
    $class = $class->GetObjectPacket()
        if $class->can("GetObjectPacket");
    ...
}
[download]

(in part, because I prefer to keep my class methods and object methods in separate 'package's anyway)

- tye