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 ]

heusserm (4461)

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

Matt Heusser is JAPH and an XP-Er []. (The Methodology, not the Operating System.) Right now, he's doing a lot of Test Driven Development in Perl.

Journal of heusserm (4461)

Monday September 08, 2003
07:19 AM

Container Classes in Perl?

[ #14576 ]
It seems that every introduction to Object Oriented Code these days has a "container class."

You know, a class that holds other classes. Something described in "Design Patterns" by the Gang Of Four (GOF).

The thing is, you often don't need one in perl.

Perl has two built-ins that meet the need for this: Hash and Array. Arrays probably meet the need the best.

They are as big as you need them to be.
You can push and pop them.
You have two built-in ("Free") iterators: For and Foreach.
You have random-access by index, and length functions.

Why would anyone "need" a container class (by default) when you can just declare an anonymous array?

Sure, there might be specific times when a container class would be nice - when you are doing some complex HTML slicing again and again, for instance. In that case, go ahead, use a container.

But, in general, I think a container class is a purist, or "perfectionist" ideal that may not add practical value, yet will increase lines of code. And lines of code adds a maintenance burden.

So, I would argue that, in perl, in general, use arrays instead of writing container classes.

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.
  • You're wrong.

    Using specific container classes helps you to document behaviour. It should help you put appropriate behaviour in the right place and move shared behaviour into superclasses.

    Ask James Duncan about the trials of dealing with a mature application that is mostly OO but with a largish datastructure that was initially implemented with anonymous hashes and arrays. The up front laziness cost them time and time again as they came to extend the system and they all sorts of fun trying to replace it wit
    • pdcawley does echo my thoughts on this. In large systems often you don't want to just be push'ing on or pop'ing from an array. You want to be doing things like validation of values that are being push'ed and pop'd.

      If you want to be doing validation then you want to ensure that you Don't Repeat Yourself. You also want to make sure that the behaviour is close to the data. In short, you want a class.

      For sure, with Perl, you could tie the Array or Hash, but, there is a problem with that. First, Tie'ing
  • The popular statically typed languages often have difficulty with containers because they have to fit into the static typing scheme. (Of course, if you're using a weakly typed language such as Java or C, you can just cast to the appropriate void and cast back, if you aren't bothered by such things as good taste.)

    Thankfully, Perl avoids that route, caring only about the container type, as references fit into scalars.

    • I think Dominus covers this well in a talk he did for a Perl Conference [].

      Pay special attention to 4 [], 5 [] and 6 [].

      ObFanBoyStatement: Dominus is so cool. Who else has the courage to point out that those who parade around in Design Patterns for Software are naked?

      • Lots of people. Doesn't make 'em any more right though. Just because the Gang of Four book is not a good patterns book doesn't mean that patterns have no value. Take a look at Kent Beck's Smalltalk Best Practice Patterns for a superb example of a pattern language. Martin Fowler's Refactoring is also a great patterns book.

        The GoF book isn't a pattern language, it's just a collection of 'words'.