Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday September 13, 2007
08:51 AM

The Perl Book We Need

[ #34440 ]

How often do you see this in code?

sub new {
    my $class = shift;
    return bless [] => $class;

Not very often. However, I'll bet you often see errors like this:

my $cust = Customer->new($id);

# violates encapsulation
print $cust->{name};

# violates encapsulation again! (unless internal):
if ( $cust->_preferred ) { ... }

# bad interface if the following fails:

# Hello Demeter!  (Yeah, this is contrived)
my $office = $cust->salesman->manager->office;

What I would like to see is a book which focuses on OO programming for Perl, but with two primary considerations. The first is to focus primarily on what people are likely to encounter in the wild: blessed hashrefs. The second consideration is teaching them how to think about OO programming.

Intermediate Perl and Object Oriented Perl both have great things to say on these topics, but neither is quite what I would like to see out there. Unfortunately, many Perl programmers learn the syntax of OO in Perl but they don't learn OO. Blessing a hashref isn't enough. Instead, I'd love to see more Perl programmers who can reasonably discuss:

  • Responsibility-driven design.
  • The difference between class and instance data/methods.
  • How inheritance breaks encapsulation.
  • When to throw exceptions.
  • Composition via delegation.
  • Class consumers versus class cooperators.
  • Why the Liskov Substitution Principle is important.
  • Polymorphism and allomorphism.

This wouldn't be a design pattern book. This would not be a syntax book. It would be something which would open up the eyes of Perl programmers regarding OO, but it would be straight-forward. Want class data? Use Class::Data::Inheritable and explain the concept. Need delegation? Use Class::Delegator and explain the concept. It's not to claim the the tools the book uses are best practices. It's to claim that the ideas the book uses are best practices. That's why it would mention blessed array references, but all examples would be blessed hash references. That's what you're likely to see and it's more important to focus on the concepts than the implementations.

So, um, somebody go out and write the damned thing.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • It's already been written. It just doesn't use Perl. Good design transcends language.

    But, this book wouldn't sell. It would be a great book, but no one would buy it (where no one means fewer people than it takes to keep the economic incentive above working at Starbucks instead).

    I don't see the word "Perl" in the title magically making this a sellable or interesting book. People interested in good design are the same people that read about design despite the language.

    I here rumor that the Perl book topics wi
  • ... you want to educate the masses.

    And unfortunately, for the most part (rare exceptions like Perl Best Practices excluded) books don't educate the masses.

    Things like perlcritic rules are far more likely to have the impact that you want.

    I think there's a number of interesting perlcritic rules that could be implemented based on your examples (most of which I agree with)
  • I recently had the good fortune to attend Damian's Intermediate OO class and he does an excellent job of covering the concepts and context for many of the issues you raise. We just need to send every perl coder to Damian's course! :)
  • "Why the Liskov Substitution Principle is important."

    It's important for academics who are more concerned with being correct than useful.

    Override nothing! Delegate everything!

    Ok, maybe I'm a wee bit bitter after losing a debate about Pathnames, Strings and subclassing.

    • I think you must be thinking about something else. Liskov doesn't say anything about not being able to override anything. It merely states that a subclass must be substitutable for the parent class without affecting the correctness of a program. You can override all you want, just make sure that the interface doesn't change.

  • # Hello Demeter!  (Yeah, this is contrived)
    my $office = $cust->salesman->manager->office;
    What's wrong with this?
    • my $office = $cust->salesman->manager->office;

      It's a question of encapsulation. Imagine that the Salesman class no longer has need of a manager accessor, but you still need to know which office the salesman is with. You might get a office method pushed into the Salesman class. Then, every place where you have the above code needs to be changed to:

      my $office = $cust->salesman->office;

      If that's called a lot, it can be a maintenance nightmare.

      However, what if you have this?

      sub Cus

      • You've properly encapsulated the hierarchical structure and greatly improved maintainability. Oh, I see what you mean now. Right, thanks.
        • You're welcome. It's not exactly intuitive. Took me a couple of tries to get it :)

      • Thank you. I hadn’t realized Moose’s powerful delegation mechanisms we’re more than handy shortcuts. This provides an excellent use case for them.

        For those who don’t know Moose every attribute object can have a handles er … attribute … so the example here can be defined like:

        package Salesman;
        use Moose;

        has manager  => (
            handles => [qw( office )],

        package Cusotomer;
        use Moose;

        has salesman => (
            isa => 'Salesm

        • Thanks for very thoughtful approach to teaching OO. Unfortunately, in my college days we learned OO in a worsed possible way (questionable faculty, clueless students, books never used).