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.

---

---

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! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

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:
	&		&
	<		&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.