Object-oriented programming#

Perl has two object systems living side by side: the modern class/field/method syntax introduced in 5.38 (codename Corinna), and the classical bless/@ISA model that predates it by three decades. pperl supports both, and both appear in real code you will read and maintain.

The short version:

  • For new code, use class. The syntax is first-class, the constructor is generated for you, fields are genuinely private, and single inheritance has a clean declarative form.

  • For legacy code, understand bless, @ISA, and the $self = shift convention. You will meet them in every pre-5.38 codebase, every mainline CPAN distribution, and much of core Perl itself.

  • Moose, Moo, Class::Accessor, Object::Pad are the CPAN ecosystems that papered over the classical model’s rough edges while the core feature was still being designed. They are a historical chapter; new code reaches for core class instead.

This how-to tree covers both systems end-to-end. Read the chapters in order on a first pass, or jump to the one that matches the code in front of you.

Which chapter you want#

  • Modern classes — class, field, method, ADJUST, :param, :reader. The recommended way to write OO in pperl.

  • Classical OO — bless, @ISA, sub new, accessors by hand, SUPER::. The model you will maintain in existing code.

  • Inheritance and method resolution — how method lookup works, isa, can, DOES, MRO, and the pitfalls of multiple inheritance.

  • Roles and delegation — composition patterns for behaviour shared across unrelated classes.

  • Migrating from classical to modern — a mechanical recipe for converting a bless-based class to the class feature, and the places where the translation is not mechanical.

When to use OO at all#

OO is a tool, not a style. Reach for it when:

  • The problem has a small vocabulary of nouns (user, session, request, record) and a larger vocabulary of verbs acting on each.

  • A piece of data carries invariants that should be enforced at one point in the code, not at every call site.

  • You expect the implementation behind a set of operations to change while the operations themselves stay stable.

  • You are modelling a category with variants and want polymorphism to pick the right behaviour.

Do not reach for OO when:

  • The program is small, linear, and has no reusable nouns.

  • A plain hash of hashes or a closure is enough.

  • The only reason to write a class is “it felt more professional.” A twelve-line script does not need a class.

A note on scope#

This tree is a tutorial, not a reference. The exhaustive syntax tables live in the per-keyword reference pages:

Link into them whenever you need the full signature surface; this tree gives you the working-programmer overview.