Wow!

What a post. ++ to you dude.

A few minor thoughts. You need to be careful about transplanting idioms and the like from other langauges into perl. While its not strictly speaking _wrong_ it does lose a lot of the elegance and beauty of Perl. To what do i refer?

sub setPhrase {
  my $self = shift;
  my $phrase = shift;
  $self->{phrase} = $phrase;
}

sub getPhrase {
  my $self = shift;
  return $self->{phrase};
}
[download]

This has "i learned to program OO with java" written all over it. :-)

First off it breaks the generally held style of conventions of Perl, which I wont get too hung up about except to quote from perlstyle.

It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS.

Java perhaps never considered the ease of use of its conventions outside of the English community (standard English speakers blindness) but as so many contributors and programmers of Perl are non-native english speakers its taken a bit more seriously in Perl circles.

The second point about this is that the seperate set/get accessors are not at all a perl convention. In Java I suppose it makes sense due to method signatures and the like, but with Perls flexible calling conventions it is _much_ more common to see property accessors writen like this:

sub Phrase {
  my $self=shift;
  $self->{phrase}=shift if @_;
  return $self->{phrase}
}
[download]

or like this

sub Phrase {
  my $self=shift;
  if (@_) {
     $self->{phrase}=shift;
     return $self;
  }
  return $self->{phrase}
}
[download]

I personally prefer the latter as it allows for method chaining:

my $dump=Data::Dumper->new([$foo])->Terse(1)->Purity(0)->Names(['foo']
+)->Dump()
[download]

This is an extremely common convention in perl and should not be ignored by a class/module designer.

Personally I wont use classes (except as a last resort) with the type of accessor design that you describe. Its too clunky and noisy for my tastes. Perl is supposed to flow like poetry...

It is considered bad form for an object to die().

I dont understand where you got this idea from. eval{} die() are perls standard exception handling mechanism. I dont think the alternatives are anywhere near as useful or powerful for many tasks, and often result in torturous code. Of course that doesnt mean that one shouldnt take advantage of undef returns and the like as well, but personally if it means gunking up the interface to avoid dying I wont. Some things (like opening a file) IMO _should_ die when they go wrong.

my $saver  = new Saver::Database($db, $user, $pass);

This one I also have a problem with. I do not think that it is at all a good idea in a tutorial to recommend what is generally considered bad practice (unfortunately this particular one is all too common). The indirect object syntax is dangerous and should be avoided. It doesnt always parse the way one might think it should and when it doesnt the bugs are _hard_ to track down. Much better to use the absolutely unambiguous

my $saver  = Saver::Database->new($db, $user, $pass);
[download]

Especially when teaching potential beginers.

My last thought goes back to an earlier one. Perl provides great flexibility in interface design. It is well worth the effort to utilize this flexibilty to give your classes and objects intuitve and easy to use interfaces. For instance:

$quote1->setPhrase($phrase);
$quote1->setAuthor($author);
[download]

If I thought that this was going to happen anymore often then very very rarely I would replace that with a

$quote1->Quote($phrase,$author);
[download]

or maybe (actually probably not, but possibly)

$quote->Set(phrase=>$phrase,author=>$author);
[download]

Anyway, dont get these comments wrong. My primary intention is to point out that importing concepts from other languages is a fine thing, but it shouldnt go so far as to obscure the beauty elegance and power of Perl.

From what I can tell this is a worthy post and I thank you for your efforts. I will definately be voting that this goes to tutorials.

(Although i think you should link to the standard Perl OO tutorials:perlboot perltoot etc...)

Once again, kick ass post ++

Ps: Next time you write something this big stick a few readmore tags in... :-)

--- demerphq
my friends call me, usually because I'm late....

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.