package Err;

sub new {
    return bless {}, shift;
}

sub err {
    my $self = shift;
    my %args = @_;
    # Do something with %args here
}
[download]

$handler ||= new Err;
# time passes
&do_right_thing() or $handler->err(title=>'Oops',msg=>'something went 
+wrong');
[download]

At this point, since you've not shown the need for inheritance implementation reuse or even interface reuse, I'd stay away from the complexity of objects. My personal rule is not to pull in OO technology in Perl until the line count of the program exceeds about 1000 lines, and using all the OO features of abstraction, inheritance, and data hiding all becomes useful. So far, all you've done is named a data structure. {grin}

-- Randal L. Schwartz, Perl hacker

I agree that OO is not a great wheel for this case. But I do see two points with that code. The first is that you probably want your error message put into the handler, and not the constuctor. (Which is why I posted.) The second is that you get an indirection layer.

OTOH if the indirection layer is all that is desired, then a reference to a sub does that without the OO machinery hanging around.

Incidentally I don't like to put full OO designs into a ton of code either. However I do like trying to put some sort of indirection in early. But to do it in a way where I can behind the scenes figure out how to do it better later.

For instance some of the arguments will likely go into many messages, so the code I posted could have been improved to

package Err;

sub new {
    return bless {@_}, shift;
}

sub err {
    my $self = shift;
    my %args = (%$self, @_);
    # Do something with %args here
}
[download]

Now, while OO probably still isn't a great fit, at least I have done more with it than provide a level of indirection in how the subroutine is named. :-)

One programming principle is "optimizing for the common case". The common case here is that I create a new "err" call in a script, as above. If I switch the OO style, instead of writing out 'err' each time, I'm now writing out '$err->err', so the solution makes more work in the common case.

What about the magic that CGI.pm uses, where you can call routines with an OO style, or with a procedural style, and you don't even have to start with "new CGI", because there's a default object created. Can someone explain that?

As far as fetching the caller's package, perl makes that easy: $callers_pkg = caller;

I did end up using that in an inbetween module once, with the logic of "If my caller's package has defaults use those, otherwise use the defaults in CGI::Err". It worked, but that didn't seem clean either...

Thanks for any further comment. -mark

The trick that CGI uses is all in the following sub:

sub self_or_default {
    return @_ if defined($_[0]) && (!ref($_[0])) &&($_[0] eq 'CGI');
    unless (defined($_[0]) && 
            (ref($_[0]) eq 'CGI' || UNIVERSAL::isa($_[0],'CGI'))
                 # slightly optimized for common case
            ) {
        $Q = $CGI::DefaultClass->new unless defined($Q);
        unshift(@_,$Q);
    }
    return @_;
}
[download]

They preprocess the args to every function this way, and as long as the first arg is 'CGI' or an object that inherits from CGI they leave the arguments alone. Otherwise they prepend a global to the list.

This is nice but imposes quite a bit of overhead.

Another way of doing the same thing is to make the procedural interface be in a different package, and have a well thought-out AUTOLOAD sub that creates needed procedural wrappers at run-time. More complex but probably more efficient than what CGI does.

Another solution that I have used is to think functionally. There you actually have your error handler be an anon sub. By default it is your default, but it can be anything you want. In this case you would leave your package alone and in your CGI script say:

$handler ||= \&Err::err;
# time passes
do_the_right_thing() || $handler->(title=>'Oops',msg=>'something went 
+wrong');
[download]

If $handler is left alone, well you get the default. But anyone who wants can change it.

I have often found that this functional approach is a more efficient way to implement optional hooks. YMMV.