Preface & Thanks

What's this book about?

This book is about the Laziness--on a grand scale.

It's about how to create bigger, more robust applications that require less effort to built, less time to debug, fewer resources to maintain, and less trouble to extend.

Specifically, it's about how to do all that with the object-oriented features of Perl--how those features work and how to make use of the many labor-saving techniques and "tricks" that they make possible. Presenting these new language features requires only a few chapters (specifically, chapters 3 to 6), but the range of programming styles and idioms they make available would fill several books. This book concentrates on the most useful and powerful ways to use object-oriented Perl.

This book is also about the tremendous flexibility of Perl's approach to object orientation, and how--in Perl--there's almost always more than one object-oriented way to solve a given problem. You'll find that the text revisits a few key examples time and again, extending and reimplementing them in various ways. Sometimes those changes will add extra functionality to a previous example; sometimes they'll merely illustrate an alternative solution with different strengths and limitations.

This book is about helping you to develop new Perl programming skills that scale. Perl is a great language for "one-line-stands": ad hoc solutions that are quick, cryptic, and unstructured. But Perl can also be a great language for developing large and complex applications. The only problem is that "quick, cryptic, and unstructured" is cute in a throw-away script, but not so amusing in 5,000 or 50,000 lines of application code. Object-oriented programming techniques are invaluable for building large, maintainable, reusable, and comprehensible systems in Perl.

Finally, this book is about how Perl makes object-oriented programming more enjoyable and how object-oriented programming makes Perl more enjoyable too. Life is too short to endure the cultured bondage-and-discipline of Eiffel programming or wrestle the alligators that lurk in the muddy semantics of C++. Object-oriented Perl gives you all the power of those languages (and more!) with few of their tribulations. And, best of all, like regular Perl, it's fun!

Who's this book for?

This book was written for the whole Perl community. In other words, for an eclectic range of people of wildly differing backgrounds, interests, and levels of experience.

To that end, it starts slowly, assuming only a basic familiarity with the core features of Perl itself: scalars, arrays and hashes, pattern matching, basic I/O, and simple subroutines. If these things sound familiar, this book is definitely for you. If they don't, chapter 2 provides a quick refresher course in everything you'll need to know.

The only other assumption that's made is that you're interested in object orientation. Maybe you've only heard about its many advantages. Maybe you're familiar with the basic concepts (if not, see chapter 1). Maybe you've already had some experience--even a bad one!--in another object-oriented language. If so, you might find appendix B a useful place to start.

If you've already dabbled in object-oriented Perl--perhaps blessed a hash or two--this book is also for you. If you start at chapter 4, you'll find a range of increasingly specialized techniques to expand your repertoire and, maybe, even challenge some of your notions about object-oriented programming.

If you're an experienced object-oriented Perl programmer, this book's for you too. The earlier chapters might contain a few tricks you haven't seen before--blessed a regular expression or a typeglob lately?--and the later chapters may suggest some novel approaches you haven't considered. (The section on generic trees in chapter 12, for example, is worth a look.)

Even if you're a Perl guru, this book's still for you. Check out chapter 7, where object methods that don't have a class are called on class objects that don't have a method. Or try chapter 11, where objects are stored as one of their own attributes. Or explore chapter 13, where the entire dispatch mechanism is replaced with one that provides multiply dispatched methods and subroutine overloading.

So what is object-oriented Perl?

Object-oriented Perl is a small amount of additional syntax and semantics, added to the existing imperative features of the language. Those extras allow regular Perl packages, variables, and subroutines to behave like classes, objects, and methods.

Object-oriented Perl is also a small number of special variables, packages, and modules, and a large number of new techniques, that together provide inheritance, data encapsulation, operator overloading, automated definition of commonly used methods, generic programming, multiply-dispatched polymorphism, and persistence.

It's an idiosyncratic, no-nonsense, demystified approach to object-oriented programming with a typically Perlish disregard for accepted rules and conventions. Object-oriented Perl draws inspiration, and sometimes syntax, from many different object-oriented predecessors, adapting their ideas to its own needs. It reuses and extends the functionality of existing Perl features and, in the process, throws an entirely new slant on what they mean.

In other words, it's everything that regular Perl is, only object-oriented.

What object-oriented Perl isn't

Perl was not originally designed--or implemented--as an object-oriented language. Its version of object orientation is simple and well integrated, but not fundamental to the language.[1]

That evolutionary development shows in the few places where object-oriented features of the language are still experimental or incomplete. For example, recent versions of the Perl compiler support weakly typed variables, which provide compile-time checking and optimization for accesses to the data stored in Perl objects. But the current version of the mechanism doesn't actually enforce type safety or proper data encapsulation, nor does it fully support inheritance.

Because Perl wasn't originally designed as an object-oriented language, object-oriented Perl isn't fast. Calling a method through an object is significantly slower than calling a regular Perl subroutine. Just how much slower is a matter of some debate, and depends on whether you measure entire software systems or just raw single-call invocation speed.

A single method call is about 30 percent slower than a regular call to the same subroutine (depending on your hardware, your operating system, the phase of the moon, etc.) But though they're individually much slower, method calls are more powerful than regular subroutine calls, due to a feature known as polymorphism (see chapters 1 and 7). In a larger system, that redresses the speed imbalance in a little, but, in general, it's fair to say that an object-oriented implementation of a system in Perl will almost never be faster than the equivalent non-object-oriented implementation, and will usually be somewhere between 20 to 50 percent slower.

Those figures are enough to turn many people away from object-oriented Perl, and that's a pity because then they miss out on the many compensating benefits of object-oriented design and implementation: simpler analysis methods, a domain-oriented approach to design, cleaner and more compact code, more robust implementations, greater code modularity, easier debugging, more comprehensible interfaces to modules (including operator-based interfaces), better abstraction of software components, less namespace pollution, greater code reusability, scalability of software, and better marketability of the final product.[2]

The sad thing is that people get spooked by the numbers (20 to 50 percent slower!!!) and forget what that really means (...just as fast in six months time, when processor speeds have doubled).

About this book

This book is arranged as a tutorial on the object-oriented features of Perl, and the many techniques developed for using those features.

Chapter 1 provides a quick revision of the fundamentals of object orientation: objects, classes, attributes, methods, inheritance, polymorphism, aggregation, interfaces, genericity, and persistence. Chapter 2 offers a refresher on aspects of the Perl language most relevant to object-oriented Perl: basic data types, subroutines and closures, references, packages and modules, typeglobs, and the CPAN.

Chapter 3 introduces the basic features of Perl's object-oriented mechanisms, concentrating on the most commonly used way of building classes and objects. Chapters 4 and 5 explore numerous other ways of implementing objects in Perl. Chapter 6 introduces Perl's inheritance mechanism and chapter 7 discusses Perl's approach to polymorphism.

Chapter 8 describes two freely available packages that can be used to automate the creation of class methods and attributes. Chapter 9 describes the Perl tie mechanism, which allows objects to be accessed like regular Perl variables or filehandles. This theme is continued in chapter 10 where Perl's operator overloading facilities are introduced.

Chapter 11 looks at the problem of Perl's poor support for encapsulation and suggests three class implementation techniques that can be used to protect attributes within objects. Chapter 12 explains why generic programming techniques are rarely needed in Perl and suggests several useful approaches for the few situations where they are required.

Chapter 13 looks at a generalized form of polymorphism known as multiple dispatch, which allows every argument of a method call to contribute to the invocation process. Chapter 14 examines how persistence techniques can be integrated with an object-oriented system.

Appendix A provides a condensed summary of Perl's object-oriented features, with examples of the syntax for each. Appendix B provides an overview of those same features designed to assist programmers who are already familiar with one of four major object-oriented languages: Smalktalk, C++, Java, and Eiffel. A glossary of important object-oriented terms is also provided.

Throughout the text, each feature and technique is introduced with an example of a common type of programming problem that the feature or technique helps to solve. If you're looking for a specific technique to solve a particular problem, here's a list of the example problems and the chapter and section in which they're discussed. The words (and following) indicate a major example that continues in subsequent sections of the same chapter.


The small number of names on the cover of most textbooks--in this case, just one--is an outright deception. Every textbook is a collaboration of a large number of dedicated and talented people. In writing this book, I have been guided, helped, and supported by a multitude of generous and wise people. I am especially grateful to...

My beloved Linda, who has borne most of the burdens of our daily life these past six months, and who still found time to contribute her wisdom and insight to this book. Every day she sustains me with her extraordinary beauty, grace, and love; she is my inspiration, my joy, and my light.

My parents, James and Sandra, for their faith, love, and very practical support over so many years. They have been the giants on whose shoulders I stood.

My parents-in-law, Corallie and Fred, for their encouragement, their kindness, and their love over the past decade.

Tom Christiansen, for his extraordinary generosity in reviewing the entire manuscript at short notice and in record time. His suggestions have sharpened my prose and my Perl immeasurably.

Nat Torkington, who has been a constant source of wise counsel, practical assistance, and a host of favors far beyond the call of friendship, duty, or even antipodean solidarity.

Randal Schwartz who somehow found time in his insanely busy life to review the entire manuscript, and to suggest many significant improvements.

Bennett Todd, whose excellent advice, unflagging enthusiasm, and endless encouragement, have buoyed me through some very dark hours.

Uri Guttman, whose meticulous last-minute review suggested many subtle changes that greatly enhanced the final manuscript.

Mark-Jason Dominus, whose insight and experience were instrumental in setting the overall structure and direction of my early drafts, and whose guidance I have sorely missed ever since.

The many other reviewers of my manuscripts, who have devoted extraordinary amounts of time, effort, and ability to dissecting my English and my Perl: Ilya Zakharevich, for his expert advice on the care and feeding of operators; Graham Barr, for finding some very subtle bugs--both in my programs and in my writing; Tim Bunce, Fran?ois D?sarm?nien, Brian Shensky, and Adrian Blakey, for knocking my SQL into shape; Chris Nandor, for a thorough dissection of the toughest five chapters; Gary Ashton-Jones, for highlighting the important of sequence; Leon Brocard, for keeping the focus where it ought to be; David Cantrell, for his tremendous attention to detail; and John Dlugosz, for making me question so many assumptions.

The many other members of the Perl community who have shared their knowledge and understanding with me and helped to resolve all manner of finer points of Perl lore over the years.

My colleagues at Monash University, for their support and encouragement. In particular: David Abramson, John Crossley, Trevor Dix, Linda McIver, Steve Welsh, and Ingrid Zukerman.

Marjan Bace and the staff of Manning Publications, who have guided and encouraged me at every stage of development with patience, good humour, and very practical support: Brian Riley and Peter Schoenberg, who watched over me; Ted Kennedy, who masterminded the review process, adding his own invaluable suggestions; Ben Kovitz, for his guidance and advice on the material itself and for his inspiring illustrations; Mary Piergies, who turned a raw manuscript into a polished book; Adrianne Harun, who edited away the worst faults of my original copy, and Tony Roberts; who worked typesetting miracles.

And, finally, Larry Wall, for giving us all this wonderful adventure playground called Perl.

1 it is in Java, or Eiffel, or Python, for example.

2   Not to mention that, according to its more extreme proponents, object-oriented programming apparently builds cardiovascular fitness, reduces weight, lowers cholesterol, makes money fast, promotes world peace, and improves your love life.