The way in which you're using the -> operator and AUTOLOAD() is perfectly valid. Your solution is a very clean and perl-ish way to build the API that you need.

The really nifty thing about the Perl OO framework is how open and flexible it is. As with most everything else Perl, you have a great deal of choice in how you select/combine the OO features of the language for your particular application/architecture.

As you say, the -> operator is syntactic sugar. But that's not because of how you're using it -- it's *always* syntactice sugar. Really, really useful syntactic sugar. You never have to use the -> operator: you can "drop down a level" and think about Perl objects more along the lines of the way you might think about C structs:

 # common, clean, readable, OO-ish way
 $foo->bar ( 'bash' );

 # less common, probably less readable, way
 Foo::bar ( $foo, 'bash' );
[download]

You can even intermix the two calling styles, if you really want to.

As for leaning on AUTOLOAD(), check out how Socket.pm uses it:

# from 5.6.1's Socket.pm on Linux 2.4
sub AUTOLOAD {
    my($constname);
    ($constname = $AUTOLOAD) =~ s/.*:://;
    my $val = constant($constname, @_ ? $_[0] : 0);
    if ($! != 0) {
        my ($pack,$file,$line) = caller;
        croak "Your vendor has not defined Socket macro $constname, us
+ed";
    }
    eval "sub $AUTOLOAD () { $val }";
    goto &$AUTOLOAD;
}
[download]

Heh. Most of the XS-dependent core modules do really hairy things with AUTOLOAD(). In comparison, your stuff is a paragon of the virtuous, straight and narrow.

If you want to make the separation between your various MessageLibrary objects clear, you have a few choices. You could add a settable "type" field that would differentiate them. But a more OO-ish way -- if your collections of error messages are pretty stable -- would be to code up the different Library types as classes themselves (MessageLibrary::Error, MessageLibrary::Debug, etc), all inheriting from the base MessageLibrary class. With a properly-written constructor, probably the only thing that would need to be overridden in each child would be the hash of messages. Here's how I tend to code such things (each package in a separate file, and with a framework for calling a class-specific _init() sub, which is often necessary).

package MessageLibrary;
use ...

my $hash = { ... };

sub new {
  my ( $class, %args ) = @_;
  my $self = {}; bless ( $self, $class );
  $self->_init();
  return $self;
}

sub _init { ... }
sub AUTLOAD() { ... }

1;

#-----------------------------

package MessageLibrary::Error;

my $hash = { ... something different ... }

sub _init {
  my ( $self, %args ) = @_;
  ... class-specific init code, if needed ...
  $self->SUPER::_init ( %args );
}

1;
[download]

Damian Conway's book Object Oriented Perl (isbn ISBN 1884777791 )is a really terrific tutorial and reference on all things Perl-OO.

Thanks for an extremely informative response. I feel much better knowing I'm not the only one using AUTOLOAD like this ;-)

I agree with you about Damian's book: I just bought it the other day and I'm feeling enlightened already.

Using an inheritance trick, polymorphism, you could subclass each of the specific MessageLibrary objects so that instead of having different methods in one class, you have many classes with a common overloaded method:

my $file_error = Error::FileOpen->new();

open MYFILE, $myfile or die $file_error->handle($myfile);
[download]

I think i'd just rather use:

open MYFILE, $myfile or die $error_messages->generate_message(
   'file_open_failed', 
   $myfile
);
[download]

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)

Thanks for the feedback... and just to clarify, when it comes to tailoring errors I am not actually adding code within the MessageLibrary class itself, but specifying it in the object constructors, something like this:

my $error_messages = MessageLibrary->new({
  file_open_error => sub{"Couldn't open $_[0]: $!"},
  bad_token => sub{"Invalid token $_[0] encountered on line $_[1]"},
  bad_file_format => "Invalid file format",
});
my $status_messages = MessageLibrary->new({
  starting_parse_phase => "Starting parser...",
  generating_results => sub {"Generating results for element $_[0]"},
});
[download]

So basically the only stuff in the class package is just a constructor, an AUTOLOAD method, and a couple of little utility methods.

Update: While rereading this response, I realized there was an aspect of jeffa's point about not having to tailor error messages that I only partially answered. Although you can define error messages in the object constructor, the object also provides default handling for any method you might call. So you could do this: print $status_messages->undefined_msg($a_param, $another); and get a reasonable result. (You can also override this default behavior in the object constructor.)

-- Randal L. Schwartz, Perl hacker

Class::Prototyped looks like great stuff -- thank you. Now to go digest the meaning of it all ;-)

In fact, sounds like code that we all might find useful.

One idea: would you want to make it so that you had four classes, one abstract MessageLibrary class, and three others for each type. You might find in the future that the different types of errors needs different methods of some type. It would also be easier to read because you would know what type you are dealing with. Just an idea that I hope helps.

Thanks for the compliment, and I've just posted the code and POD on my site for all to see (gulp). Here's the link:

http://www.clyman.com/s/pm/messagelibrary/

This is my first time releasing code into the wild (aside from stuff I've given to clients unlikely to ever look under the covers!)... comments, suggestions, etc. would be much appreciated.

What you have done that is wholly appropriate is to encapsulate the behavior of your objects using an idiom that you've come up with. It shouldn't be too hard to maintain this at the current level of usage.

Should you decide that this message object should be mutated and ubiquitous, then you might want to consider developing more O-O type software. Till then, I'd let it slide.

Drew

Be careful what you wish for... (Mr. Limpet)

For where you treasure is there shall your heart be also (Christ)