In the last post we investigated prototype subroutines in Perl. In this post, we will look at operator overloading, which allows you to define how operators behave for objects of a class.

An operator in programming is a symbol or keyword that performs a specific operation on one or more operands (values or variables). There are many types of operators, such as arithmetic operators (like +, -, *, /) and comparison operators (like ==, !=, <, >).

In Perl, you can overload these operators for your own classes, allowing you to define custom behaviour when these operators are used with objects of that class. The following table can be used as a reference to operators that can be overloaded in Perl:

All of these operators can be overloaded by defining methods in your class that correspond to the operator. For example, to overload the addition operator (+), you would define a method named add in your class. And then you can use the use overload pragma to associate that method with the + operator.

When overloading in Perl, the fallback option is important to set because it tells Perl what to do if an operator is used on your object but you haven’t provided an explicit overload for that operator. It will fallback to the default operator. If you do not set fallback then perl will throw an error when your object is used with an unimplemented operator.

Today we will create a new module that will represent a simple mathematical 3D vector. We will overload the addition, subtraction, multiplication, stringification operators for this example. Lets start by creating a new distribution called Math::Vector3D using Module::Starter:

module-starter --module="Math::Vector3D" --author="Your Name" --email="your email"

This will create a new directory called Math-Vector3D with the basic structure of a Perl module. First we will add a new test file to test our module. We will start simple by just testing the instantiation of our object. Create a new file called t/01-vector3d.t with the following content.

use Test::More;
use_ok('Math::Vector3D');
ok(my $v = Math::Vector3D->new(1, 2, 3), 'Created a new vector');
isa_ok($v, 'Math::Vector3D', 'Object is of correct class');
eval {
    Math::Vector3D->new('a', 'b', 'c');
};
like($@, qr/Invalid vector component/, 'Invalid components raise an error');

done_testing();

As you can see, we are testing the creation of a new vector object and checking that it is of the correct class. We also test that invalid components raise an error, as we only want our object to be instantiated with numbers.

Next, we will implement the new method in our module. Open the file lib/Math/Vector3D.pm and replace the function1 definition with the following code:

=head2 new

Constructor for the Math::Vector3D object.

    my $vector = Math::Vector3D->new(1, 2, 3);

=cut

sub new {
    my ($class, @vector) = @_;

    looks_like_number($_) or die "Invalid vector component: $_" for @vector;

    return bless { vector => \@vector }, $class;
}

This new method takes a list of components for the vector, checks that they are all numbers using looks_like_number, and then blesses the array reference into the class. The looks_like_number function is not a built-in function, so we need to import it from the Scalar::Util module. The Scalar::Util module is one of many core modules that come bundled with Perl, so you don't need to install it separately. To use it, we will add the following line at the top of our file after the use warnings line:

use Scalar::Util qw(looks_like_number);

Now we can run our test file to see if it passes:

prove -lv t/01-vector3d.t

You should see output indicating that all tests passed. Next we will implement stringification for our vector object. This will allow us to convert our vector object to a string representation when we use it in a string context, such as when we print it. Open the test file and extend with these tests:

is($v->stringify, "(1, 2, 3)", 'Stringification method works');
is("$v", "(1, 2, 3)", 'Stringification works');

As you can see we are testing the stringify method directly on the object, and also testing the stringification when we use the object in a string context. Now we will implement the stringify method in our module. Add the following code to lib/Math/Vector3D.pm first replacing the function2 definition:

=head2 stringify

Returns a string representation of the vector.

    my $string = $vector->stringify();

=cut

sub stringify {
    my ($self) = @_;
    return sprintf "(%s)", join(', ', @{$self->{vector}});
}

And then add the overload declaration at the top of the file after the use Scalar::Util line:

use overload
    '""' => 'stringify',
    fallback => 1;

This overload declaration tells Perl to use the stringify method when the object is used in a string context (like when interpolated in a double-quoted string). The fallback => 1 option allows Perl to fall back to the default behavior if the operator is not overloaded.

Now we can run our test file again to see if the stringification tests pass:

prove -lv t/01-vector3d.t

You should see output indicating that all tests passed. Next, we will implement the addition operator (+) for our vector object. This will allow us to add two vectors together using the + operator. Open the test file and extend with these tests:

ok(my $v2 = Math::Vector3D->new(4, 5, 6));
is($v->add($v2), "(5, 7, 9)", 'Addition with another vector works');
is($v + $v2, "(5, 7, 9)", "Addition operator works");

We create a new vector to be used in the addition tests, and then we test both the add method directly and the overloaded + operator. Now with our tests failing we will implement the add method in our module. Add the following code to lib/Math/Vector3D.pm.

=head2 add

Adds another vector to this vector.

    my $result = $vector->add(Math::Vector3D->new(4, 5, 6));

=cut

sub add {
    my ($self, $other) = @_;
    ref($self) eq 'Math::Vector3D' or die "Method called on non-Math::Vector3D object";
    ref($other) eq 'Math::Vector3D' or die "Argument must be a Math::Vector3D object";
    return Math::Vector3D->new(
        map { $self->{vector}[$_] + $other->{vector}[$_] } 0..2
    );
}

This add method checks that both the object and the argument are of the correct class, and then returns a new Math::Vector3D object with the sum of the components. The map function is used to iterate over the indices of the vector components (0 to 2 for a 3D vector) and add the corresponding components of both vectors. When overloading numeric operators you also get a third argument which is the context in which the operator was called on the object. For example the third argument will be true if the operator was called before the object (5 + $obj) and false if it was called after the object ($obj + 5). It's important to understand the first argument $self will always be the object, the $other variable will be the operand/value, the third argument is whether $other comes before or after $obj. In all of our methods today we do not need to use this context but it is good to know it exists.

With the above in place before our tests will pass we need to add the overload declaration for the + operator. Add the following code replacing your existing overload declaration:

use overload
    '+' => 'add',
    '""' => 'stringify',
    fallback => 1;

Now we can run our test file again to see if the addition tests pass:

prove -lv t/01-vector3d.t

You should see output indicating that all tests passed. Next, we will implement the subtraction operator for our vector object. This will allow us to subtract one vector from another using the - operator. Open the test file and extend with these tests:

is($v->subtract($v2), "(-3, -3, -3)", 'Subtraction with another vector works');
is($v - $v2, "(-3, -3, -3)", "Subtraction operator works");
is($v2->subtract($v), "(3, 3, 3)", 'Subtraction with another vector works in reverse');
is($v2 - $v, "(3, 3, 3)", "Subtraction operator works in reverse");

With the failing tests in place we will implement the subtract method in our module. Add the following code to lib/Math/Vector3D.pm:

=head2 subtract

Subtracts another vector from this vector.

    my $result = $vector->subtract(Math::Vector3D->new(4, 5, 6));

=cut

sub subtract {
    my ($self, $other) = @_;
    ref($self) eq 'Math::Vector3D' or die "Method called on non-Math::Vector3D object";
    ref($other) eq 'Math::Vector3D' or die "Argument must be a Math::Vector3D object";
    return Math::Vector3D->new(
        map { $self->{vector}[$_] - $other->{vector}[$_] } 0..2
    );
}

This subtract method is similar to the add method, but it subtracts the components of the second vector from the first. The same checks for class and context are applied.

Now we will add the overload declaration for the - operator. Add the following code replacing your existing overload declaration:

use overload
    '+' => 'add',
    '-' => 'subtract',
    '""' => 'stringify',
    fallback => 1;

Now run your tests again and all should pass. The next method we will implement is mutiply this will work slightly differently to the add and subtract we will allow normal multiplication between a vector and an number however when you multiple two vectors together we will calculate the Dot product of the vectors. The dot product (also called the scalar product) of two vectors is a single number obtained by multiplying their corresponding components and then adding those products together. Add the following tests to your test file:

is($v->multiply(2), "(2, 4, 6)", 'Multiplication with a number works');
is($v * 2, "(2, 4, 6)", "Multiplication operator with a number works");
is($v->multiply($v2), 32, 'Dot product with another vector works');
is($v * $v2, 32, "Multiplication operator returns dot product with another vector");

Then to implement the multiply method in our module, add the following code to lib/Math/Vector3D.pm:

=head2 multiply

Multiplies this vector by a scalar or another vector.

    my $result = $vector->multiply(2);
    ... or
    my $dot = $vector->multiply(Math::Vector3D->new(2, 2, 2));

=cut

sub multiply {
    my ($self, $other) = @_;
    if (ref($other) eq 'Math::Vector3D') {
        # Dot product
        return $self->{vector}[0] * $other->{vector}[0]
            + $self->{vector}[1] * $other->{vector}[1]
            + $self->{vector}[2] * $other->{vector}[2];
    } elsif (looks_like_number($other)) {
        # Scalar multiplication
        return Math::Vector3D->new(
            map { $self->{vector}[$_] * $other } 0..2
        );
    } else {
        die "Argument must be a scalar or Math::Vector3D object";
    }
}

This multiply method checks if the argument is a number or a Math::Vector3D object. If it's another vector, it calculates the dot product. If it's a number, it multiplies each component of the vector by that number. If the argument is neither, it raises an error.

Now update the overload declaration to include the * operator. Replace your existing overload declaration with the following code:

use overload
    '+' => 'add',
    '-' => 'subtract',
    '*' => 'multiply',
    '""' => 'stringify',
    fallback => 1;

Now run your tests again and all should pass.

This concludes today's post. We have learned the basics of operator overloading in Perl by building a simple 3D vector class. We covered how to overload arithmetic and stringification operators, and how to write tests to verify our implementation. With these techniques, you can make your own Perl classes behave more naturally and intuitively when used with Perl's built-in operators.

If you do feel inspired, you could continue building on this module. For example, you might add a magnitude method and then overload the comparison operator <=> to compare vectors. If you do come up with your own extensions or improvements, please do share them below!

In the next post we will look at phasers in Perl. Phasers are special blocks that control when certain code is executed during the compile and run phases of your program. We'll explore what each phaser does, when it runs, and practical examples of how you can use them.

Today we are going to discuss Perl subroutine prototypes, which are a way to enforce a certain structure on the arguments passed to subroutines. Prototypes can help catch errors early and make your code more readable.

In Perl, subroutine prototypes are used to define the expected number and types of arguments that a subroutine should receive. They are specified in the subroutine declaration and can include various modifiers. The prototype is placed immediately after the subroutine name. Here’s a simple example:

sub my_subroutine ($$) {
    my ($arg1, $arg2) = @_;
    print "Argument 1: $arg1\n";
    print "Argument 2: $arg2\n";
}

In this example, the prototype ($$) indicates that my_subroutine expects exactly two scalar arguments. If you call it with the wrong number of arguments, Perl will throw an error.

You can also use prototypes to enforce that a subroutine receives a key-value list or hash. For example:

sub my_hash_subroutine (%) {
    my %args = @_;
    print "Arguments as hash:\n";
    foreach my $key (keys %args) {
        print "$key => $args{$key}\n";
    }
}

In this case, the prototype (%) indicates that my_hash_subroutine expects a hash as its argument. When you call it, you should pass a hash. If you do not for example you pass a odd number of arguments, Perl will again throw an error.

The following table summarises common Perl subroutine prototypes:

Today we will apply this concept in a practical example, we will create a new functional Perl module that exports functions with prototypes to demonstrate there usage. Our module will be a basic statistics module that calculates the min, max, mean and median of a list of numbers. We will also allow them to specify a code reference as the first argument to be used to coerce the subsequent list. Think of it like custom grep or map keywords for basic statistics. Let's start by creating a new distribution using Module::Starter we will call it Stats::Basic.

module-starter --module="Stats::Basic" --author="Your Name" --email="your email"

First lets add a new test file t/01-basic.t to test our module. We will start by accessing functions by namespace and add the exporting at the end. The first function we will implement is min, which will return the minimum value from a list of numbers. Add the following to the test file:

use Test::More;
use Stats::Basic;
my $min = Stats::Basic::min { $_ } 5, 1, 3, 2, 4;
is($min, 1, 'Minimum value is correct');
my $min = Stats::Basic::min { $_->{num} } (
    { num => 5 },
    { num => 1 },
    { num => 3 },
    { num => 2 },
    { num => 4 }
);
is($min, 1, 'Minimum value from hash is correct');

done_testing();

Even some experienced Perl developers may not realise this, but when you define a subroutine prototype with a code reference as an argument, you don't explicitly use the sub keyword before the code reference. Perl automatically recognises that the argument is expected to be a code reference and will automagically figure it out, I find this to be a particularly elegant feature and will make our final implementation cleaner. Now let's implement the min function in our module. Open lib/Stats/Basic.pm and add the following code replacing the function1 placeholder:

=head2 min

Returns the minimum value from a list of numbers or a list of numbers.

    my $min = min { $_ } 5, 1, 3, 2, 4;

=cut

sub min (&@) {
    my ($code, @numbers) = @_;
    @numbers = sort {
        $a <=> $b
    } map { $code->($_) } @numbers;
    return $numbers[0];
}

As you can see we have declared our prototype &@ this signifies to Perl that our function accepts a code reference as the first argument and a list as the second. We use map to iterate over the numbers calling the code reference on each item, then the result of that is passed to sort where we sort in ascending numerical order using $a <=> $b. Finally, we return the first element of the sorted array, which will be the minimum value.

If you now run your tests using prove you will see that our basic tests pass:

prove -lv t/

Next lets extend our test file with tests for the max function.

my $max = Stats::Basic::max { $_ } 5, 1, 3, 2, 4;
is($max, 5, 'Maximum value is correct');
$max = Stats::Basic::max { $_->{num} } (
    { num => 5 },
    { num => 1 },
    { num => 3 },
    { num => 2 },
    { num => 4 }
);
is($max, 5, 'Maximum valus is correct');

Now to implement we take a very similar approach to min but switch the sorting.

=head2 max

Returns the maximum value from a list of numbers or a list of numbers.

    my $max = max { $_ } 5, 1, 3, 2, 4;

=cut

sub max (&@) {
    my ($code, @numbers) = @_;
    @numbers = sort {
        $b <=> $a
    } map { $code->($_) } @numbers;
    return $numbers[0];
}

With that in place run your tests again and all should pass. Next we will add the sum function. Lets first add the tests.

my $sum = Stats::Basic::sum { $_ } 5, 1, 3, 2, 4;
is($sum, 15, 'Sum value is correct');
$sum = Stats::Basic::sum { $_->{num} } (
    { num => 5 },
    { num => 1 },
    { num => 3 },
    { num => 2 },
    { num => 4 }
);
is($sum, 15, 'Sum value is correct');

Now to implement this in lib/Stats/Basic.pm:

=head2 sum

Returns the sum value from a list of numbers.

  my $sum = sum { $_ } 5, 1, 3, 2, 4;

=cut

sub sum (&@) {
  my ($code, @numbers) = @_;
  my $sum = 0;
  map { $sum += $code->($_) } @numbers;
  return $sum;
}

The logic is simple we have again defined the &@ prototype, this time we define a variable $sum initialised to 0, then use map to iterate over the numbers, applying our code reference to each item and adding the result to our running total. Finally, we return the accumulated sum. If you run your tests they will pass once again. The final function we are going to implement is mean. The mean is just the sum divided by the number of items so we should be able to reuse the function we just wrote. Lets first write the tests.

my $mean = Stats::Basic::mean { $_ } 5, 1, 3, 2, 4;
is($mean, 3, 'Mean value is correct');
$mean = Stats::Basic::mean { $_->{num} } (
    { num => 5 },
    { num => 1 },
    { num => 3 },
    { num => 2 },
    { num => 4 }
);
is($mean, 3, 'Mean value is correct');

To implement update your lib/Stats/Basic.pm by adding the following:

=head2 mean

Returns the mean value from a list of numebrs

  my $mean = sum { $_ } 5, 1, 3, 2, 4;

=cut

sub mean (&@) {
    my ($code, @numbers) = @_;
    my $sum = sum {$code->($_)} @numbers;
    return $sum / scalar @numbers;
}

We reuse the sum function but there is a caveat - we can't call it directly with our existing code reference. Instead, we need to create a new code reference that calls our original code reference from within. We then divide the sum by the total number of passed arguments to get the mean.

Now if you run your tests they should all pass and you now have a basic statistic module. The final task we need to complete though is the exporting of our functions so we can access them without the namespace. To do this add the following under the version declaration.

use parent 'Exporter';
our @EXPORT_OK = qw/min max sum mean/;

And that completes this post on subroutine prototypes in Perl. Through our Stats::Basic module, we've demonstrated how prototypes can be used to validate arguments and create functions that feel like natural extensions to the Perl language, similar to built-in keywords like grep and map. In the next post, we'll explore overloading of operators, which will allow you to write custom behaviour for your objects when used with certain operators.

In programming file processing is a key skill to master. Files are essential for storing data, reading configurations, and logging information. A file handle is a reference to an open file, allowing you to read from or write to that file. Today I will show you how to work with files in Perl

In Perl, file handles are used to interact with files. You can open a file for reading, writing, or appending. There are multiple ways to open a file, but the most common method is using the open keyword. The open keyword takes three arguments: a file handle, a mode, and the filename. The mode specifies how you want to interact with the file. There are multiple modes available you can use the following table as a reference to common file modes in Perl:

When you open a file, you need to specify the file handle, which is a variable that will hold the reference to the opened file. You also need to pass either a relative or absolute path to the file you want to open. open will return true if the file is opened successfully, or false if it fails. It is a good practice to check the return value of open and handle any errors appropriately.

You can use the die function to print an error message and exit the program if the file cannot be opened. This is a common practice to ensure that your program does not continue running with an invalid file handle.

Here is an example of how to open a file for reading in Perl:

open(my $fh, '<', 'file.txt') or die "Could not open file: $!";

The $fh variable is the file handle that will be used to read from file.txt. The < mode indicates that we are opening the file for reading. The or die part is used to handle any errors that may occur while trying to open the file. If the file cannot be opened, it will print an error message and terminate the program.

Once the file is opened successfully, you can read from it using various pragmas like readline and <FH>. Here is an example of reading a file line by line:

while (my $line = <$fh>) {
    print "$line";  # Print each line
}

After you are done reading from the file, it is important to close the file handle to free up system resources. You can do this using the close keyword:

close($fh) or die "Could not close file: $!";

This will close the file handle and ensure that any changes made to the file are saved properly. If the close operation fails, it will print an error message and terminate the program.

As well as manipulating files, Perl also provides a simple way to manipulate directories. You can use the opendir keyword to open a directory. The readdir keyword can be used to read the entries in the directory one by one. And closedir can be used to close the directory handle. Here is an example of how to read a directory:

opendir(my $dir, '/path/to/directory') or die "Could not open directory: $!";
while (my $entry = readdir($dir)) {
    next if ($entry =~ /^\.\.?$/);  # Skip '.' and '..'
    print "$entry\n";                # Print each entry
}
closedir($dir) or die "Could not close directory: $!";

This code opens a directory, reads its entries, and prints each entry to the console. The next statement is used to skip the special entries . and .., which represent the current and parent directories, respectively.

As well as opening, reading and writing files and directories perl also has several flags that can be used to first test whether a file or directory exists you can use the following table as a reference:

Today as an example to learn how to work with files in Perl, we will create a simple module called Personal::Log that will handle logging message to a file and then parsing the log file back to display the historical messages. This module will demonstrate how to open, write to, and read from a file in Perl.

First we will create the distribution, to do this we will use the Module::Starter module.

module-starter --module="Personal::Log" --author="Your Name" --email="your email"

This command will create a new directory called Personal-Log, which contains the basic structure of a Perl module distribution. Inside this directory, you will find a file named Log.pm where we will implement our logging functionality. First we will create a test file to test our module, we will create a file called t/01-log.t with the following content:

use Test::More;
use_ok("Personal::Log");
my $file = 'test.log';
my $log = Personal::Log->new(file => $file);
isa_ok($log, 'Personal::Log', 'Log object created');
is_deeply($log, { file => 'test.log', lines => [] }, 'Log object has correct file attribute');

done_testing();

We are have setup a basic test to check if our Personal::Log module can be instantiated correctly and if it has the correct attributes. We have two accessors for our object, file and lines. The file attribute will hold the name of the log file, and the lines attribute will hold the lines read from the log file.

Next we will implement a basic new method in our lib/Personal/Log.pm file to create a new log object. Open the Log.pm file and add the following code replacing function1.

=head2 new

Constructor for the Personal::Log object.

  my $log = Personal::Log->new(file => 'test.log');

=cut

sub new {
  my ($self, %args) = @_;

  if ( -f $args{file} ) {
    open my $fh, '<', $args{file} or die "Could not open file '$args{file}': $!";
    $args{lines} = [ <$fh> ];
    close $fh;
  } else {
    $args{lines} = [];
  }

  return bless \%args, $self;
}

This new method checks if the specified log file exists. If it does, it opens the file for reading and reads all lines into the lines attribute. If the file does not exist, it initializes lines as an empty array reference.

Next, we will implement a method to log messages to the file. First lets add new tests to our t/01-log.t file to test the logging functionality. Add the following code after the existing tests, we will return the line we add to the log:

is($log->log("This is a test message"), "This is a test message", 'Log message added successfully');
is($log->log("Another message"), "Another message", 'Another log message added successfully');

Next, we will implement the log method in our lib/Personal/Log.pm file. The log function will just log the line of text to the file and will return the line that was logged. Add the following code to the Log.pm file:

=head2 log

Logs a message to the log file.

  $log->log("This is a log message");

=cut

sub log {
  my ($self, $message) = @_;
  push @{$self->{lines}}, "$message\n";
  open my $fh, '>>', $self->{file} or die "Could not open file '$self->{file}': $!";
  print $fh "$message\n";
  close $fh;
  return $message
}

This log method appends the message to the lines attribute and writes it to the log file. It opens the file in append mode (>>), writes the message, and then closes the file.

Now we can run our tests to ensure that the logging functionality works as expected. Run the following command in your terminal:

prove -lv t/01-log.t

If everything is set up correctly, you should see output indicating that all tests passed. This means our Personal::Log module can successfully log messages to a file. You will also see the test.log file created in your project directory with the logged messages. Each time you run the tests, the log file will be appended with the test messages. However, if you do run the test currently more than once it will 'fail' because we now parse the lines. To fix this we will actually need to delete the log file when our test ends. To do this we can use the unlink keyword, which will delete the file at the end of each run. Add the following before done_testing in t/01-log.t:

unlink $file;

Now run your tests again twice and the second time it will pass as the log file will be deleted after the tests have run each time.

Finally, we will implement a method to print the current log messages to the command line. To do this add the following test to our t/01-log.t file after the existing tests and before the unlink line:

is($log->print_log, 1, 'Log messages printed successfully');

Now to implement the print_log method we will simply itterate the internal array which should contain all rows that exist in the log file and print each message to the terminal. Add the following code to your lib/Personal/Log.pm file:

=head2 print_log

Prints all logged messages to STDOUT.

  $log->print_log();

=cut

sub print_log {
  my ($self) = @_;
  foreach my $line (@{$self->{lines}}) {
    print $line;
  }
  return 1;
}

This print_log method iterates over the lines attribute and prints each message to the standard output. It returns 1 to indicate success. Now you can run your tests again and you should see the output of the log messages printed to the terminal. This completes our simple logging module in Perl.

There are many more advanced features you can implement in a logging module, such as a timestamp, different log levels (info, warning, error), log rotation and more. However, this example provides a solid foundation for understanding how to work with files and file handles in Perl and we will leave it here.

In the next post we will explore subroutine prototypes and how they can be used to validate arguments you pass to functions. Subroutine prototypes in Perl allow you to specify the expected types and number of arguments for your functions, providing compile-time checking and enabling you to create functions that behave more like built-in Perl operators. We'll see how prototypes can make your code more robust and how they enable advanced features like creating your own control structures. Until then if you have any questions ask away.

In the last post we discussed Object Oriented Programming in Perl, focusing on the basics of creating an object. In this post, we will delve into inheritance, a powerful feature of programming that allows us extend existing code with new functionality.

Inheritance is a concept that allows code to be reused and extended, and it appears in both object-oriented and functional programming, though in different ways:

In Object-Oriented Programming (OOP) inheritance means creating a new class (child or subclass) that automatically gets the properties and methods of an existing class (parent or superclass). The child class can use, override, or extend the parent’s behaviour. This helps organise code, avoid duplication, and build on existing functionality.

While functional programming doesn’t have classes, code reuse is achieved by sharing and composing functions.

In perl you can implement inheritance for any package whether it is functional or object-oriented. You can achieve this by manipulating something known as the @ISA array, which is a special array that holds the names of parent classes for a given class. A package will inherit from all packages found in its @ISA array. The @ISA array is generated by default when you use a package, it will be empty unless you explicitly set it. An example of this is shown below:

package Baz;
BEGIN {
    require Foo;
    require Bar;
    push @ISA, qw(Foo Bar);
}

The require statements will be new to you, like use, require is a way to include other Perl modules or packages in your code. The difference is that use is evaluated at compile time, while require is evaluated at runtime. This means that require can be used conditionally, and it will not throw an error if the module is not found until the code is actually executed. We wrap all the code in a BEGIN block to ensure that it is executed at compile time, before the package is fully loaded. This allows us to modify the @ISA array before the package is used. The push @ISA, qw(Foo Bar); line adds Foo and Bar to the @ISA array, meaning that Baz will inherit from both of these classes.

Setting the @ISA array directly like this is one way to implement inheritance in Perl, but it can be a bit cumbersome and error-prone, hence Perl provides some built-in pragmas to make this easier and more reliable. There are two common pragmas for this purpose: base and parent. They both allow you to specify a list of parent classes for your package to inherit from, the base pragma is just the older of the two and parent is the newer, now recommended approach, it has less cruft.

To use the parent pragma, you simply include it at the top of your package like this:

package Baz;
use parent qw(Foo Bar);

This line tells Perl that Baz is a subclass of Foo and Bar, and it will automatically set up the @ISA array for you.

Today, we’re continuing from our last post by creating a new subclass of the Note object we previously built. If you’ve been following along, this will actually be the second time we’ve used inheritance in this series.

In the Exporter post, we inherited from the Exporter module. That inheritance allowed us to take all the functionality of the module and make it available within our own package. The key method involved in that process was the import method. A special method that's automatically called when a package is used. This lets it perform actions like exporting functions in our case. We'll dive deeper into how that works in a future post on monkey patching.

In today’s example, when we inherit from our Note object, we’re doing the same thing but this time we're gaining access to all the functionality we wrote in the previous post. From there, we can extend it however we like to suit new needs.

Today we will extend our Note object to create a new subclass called Ingredient. This will allow us to add specific functionality for ingredient items while still retaining all the features of the original Note object. For the Ingredient object, we will add new properties quantity and unit, which are specific to ingredients. We will also need to modify the new method to validate these new properties and ensure they are set correctly when creating a new Ingredient object. Finally, we will need to fix the info method to include the new properties in the output.

First lets create a new test file for our new Ingredient object. We will call it t/02-ingredient.t. This file will contain the tests for our new Ingredient object, ensuring that it behaves as expected and meets our requirements. We will start by creating a basic test file that loads the Ingredient module and checks that it can be used without errors with the existing inherited functionality. Here is the initial content of t/02-ingredient.t:

use Test::More;

use Test::More;

use_ok('Ingredient');

my $ingredient = Ingredient->new(
    title => 'apple',
    description => 'fresh red apple',
);

my $last_changed = qr/\w{3}\s+\w{3}\s+\d{1,2}\s+\d{1,2}\:\d{2}\:\d{2}\s+\d{4}/;
is($ingredient->title, 'apple', 'Title is set correctly');
is($ingredient->description, 'fresh red apple', 'Description is set correctly');
like($ingredient->last_changed, $last_changed, 'Last changed is set correctly');

done_testing();

This code should be familiar to you, we are just testing the basic functionality we created in the previous post. Now we will create the Ingredient package itself. We will create a new file called lib/Ingredient.pm. This file will contain the implementation of the Ingredient object, which will inherit from the Note object. Here is the initial content of lib/Ingredient.pm that we will then expand upon:

package Ingredient;

use 5.006;
use strict;
use warnings;

=head1 NAME

Ingredient - The great new Ingredient!

=head1 VERSION

Version 0.01

=cut

our $VERSION = '0.01';

use parent qw/Note/;

=head1 SYNOPSIS

Quick summary of what the module does.

Perhaps a little code snippet.


    use Ingredient;

    my $ingredient = Ingredient->new(
        title => 'apple',
        description => 'fresh red apple',
        quantity => 1,
        unit => 'whole'
    );

    $ingredient->info; # Returns a string with the note's information
    $ingredient->title; # Returns the title of the ingredient
    $ingredient->description; # Returns the description of the ingredient
    $ingredient->quantity; # returns the required amount of the ingredient
    $ingredient->unit; # return the measurement unit for the ingredient
    $ingredient->last_changed; # Returns the last changed time in a formatted string

    $ingredient->title('Updated Note'); # Updates the title of the note
    $ingredient->description('Updated description'); # Updates the description of the note
    $ingredient->quantity(100);
    $ingredient->unit('grams');

=head1 SUBROUTINES/METHODS

=head2 new

Instantiate a new Ingredient object

    Ingredient->new(%args);

=cut

=head2 title

Accessor to get and set title attribute

    $ingredient->title()

=cut

=head2 description

Accessor to get and set description attribute

    $ingredient->description()

=cut

=head2 quantity

Accessor to get and set quantity attribute

    $ingredient->quantity()

=cut

=head2 unit

Accessor to get and set unit attribute

    $ingredient->unit()

=cut

=head2 last_changed

Accessor to access last_changed attribute, returns the epoch in localtime format.

    $ingredient->last_changed

=cut

=head2 info

Returns a string with the note's information, including title, description, quantity, unit, and last changed time.

    $ingredient->info();

=cut

1; # End of Ingredient

This code sets up the basic structure of the Ingredient package, including the necessary documentation. The only code added from a default package declaration is the use parent qw/Note/; line which indicates that Ingredient is a subclass of Note, allowing it to inherit all the properties and methods defined in the Note package.

Now if you run the test file t/02-ingredient.t, you should see that it passes successfully, indicating that the Ingredient object can be created and that it inherits the functionality from the Note object.

We are now ready to extend the Ingredient object with the new properties quantity and unit. We will need to first modify the new method to validate these new properties. By default they will already populate the internal hash, however any value will be accepted and this would then cause us potential unexpected issues later on.

Luckily in Perl it is easy to update functionality of our inherited objects in a way that we can still use the parent's functionality. In this case, we don't want to completely overwrite the parent's method and reimplement everything from scratch. Instead, we want to extend the method so that it still calls the parent, after we have validated the new arguments.

In Perl, we can do this using the SUPER pragma. The SUPER pragma allows you to call the parent class's method from within the child class.

To extend the new method in the Ingredient package, we will validate the quantity and unit properties, and then call the parent class's new method using SUPER::new. The quantity property should be a positive number and the unit property should be one of a predefined set of units. For the units we will create a global variable called %UNITS that will contain the valid units we can then use to validate against. First lets update our test file to include the additional tests for the new properties:

$ingredient = Ingredient->new(
    title => 'apple',
    description => 'fresh red apple',
    quantity => 1,
    unit => 'whole'
);

is($ingredient->{quantity}, 1);
is($ingredient->{unit}, 'whole');

eval {
    Ingredient->new(
        quantity => { not => 'valid' },
        unit => 'grams'
    );
};

like($@, qr/quantity must be a positive integer/, 'quantity validation works');

eval {
    Ingredient->new(
        quantity => 1,
        unit => 'invalid'
    );
};

like($@, qr/unit must be a valid measurement/, 'unit validation works');

Then in preperation for the new new method, we will create a global variable %UNITS that contains the valid units we want to allow. Add the following code under the use parent qw/Note/; line in the Ingredient.pm file:

our %UNITS = (
    'whole' => 1,
    'grams' => 1,
    'litres' => 1,
    'cups' => 1,
    'tablespoons' => 1,
    'teaspoons' => 1,
);

Now we can implement the new method in the Ingredient package. This method will validate the quantity and unit properties, and then call the parent class's new method using SUPER::new. Here is the updated new method:

sub new {
    my ($class, %args) = @_;

    # Validate quantity
    if (defined $args{quantity}) {
        die "quantity must be a positive integer"
            unless ! ref $args{quantity} && $args{quantity} =~ m/^\d+$/ && $args{quantity} > 0;
    }

    # Validate unit
    die "unit must be a valid measurement" if defined $args{unit} && ! exists $UNITS{$args{unit}};

    # Call the parent class's new method
    return $class->SUPER::new(%args);
}

This new method first checks if the quantity is defined and is a positive integer. If not, it throws an error. Then it checks if the unit is defined and if it exists in the %UNITS hash. If not, it throws an error as well. Finally, it calls the parent class's new method using SUPER::new, passing along the validated arguments. Now if you run the test file t/02-ingredient.t, you should see that all tests pass successfully, indicating that the Ingredient object can be created with the new properties and that the validation works as expected.

Next we will implement the relevant accessors for the new properties quantity and unit. These accessors will allow us to get and set the values of these properties. First we will add tests for the accessors in the t/02-ingredient.t file:

is($ingredient->quantity, 1, 'Quantity is set correctly');
is($ingredient->unit, 'whole', 'Unit is set correctly');
is($ingredient->quantity(200), 200, 'Quantity can be updated');
is($ingredient->unit('grams'), 'grams', 'Unit can be updated');

Now we can implement the accessors in the Ingredient package. Lets add the quantity by inserting the following code after the quantity PDD declaration:

sub quantity {
    my ($self, $value) = @_;
    if (defined $value && !ref $value && $value =~ m/^\d+$/ && $value > 0) {
        $self->{quantity} = $value;
        $self->{last_changed} = time; # Update last changed time
    }
    return $self->{quantity};
}

We are following the same pattern as we did for the title and description accessors. Here check if the value is defined, not a reference, is a positive integer, and then set the value in the object’s internal hash. We also update the last_changed time to reflect that the object has been modified. We do not error out if the value is not valid, instead we just return the current value. Next we will implement the unit accessor by inserting the following code after the relevant POD declaration:

sub unit {
    my ($self, $value) = @_;
    if (defined $value && exists $UNITS{$value}) {
        $self->{unit} = $value;
        $self->{last_changed} = time; # Update last changed time
    }
    return $self->{unit};
}

This again follows the same pattern, this time we simply need to check if the passed value is in our global %UNITS variable. We also remember to update the last_changed time to reflect that the object has been modified.

With both of those accessors in place your tests should now pass once again. The final task to complete our Ingredient object is to update the existing info method to reflect the new information we now have available. To do this we will just overwrite it's existing functionality so not call SUPER. Lets add our final test of the day:

like($ingredient->info, qr/Ingredient: apple, Description: fresh red apple, Quantity: 200 grams, Last Changed: $last_changed/, 'Info method returns correct information');

Now to implement the info method, we will add the following code to the Ingredient package:

sub info {
    my ($self) = @_;
    return sprintf(
        "Ingredient: %s, Description: %s, Quantity: %s %s, Last Changed: %s",
        $self->{title},
        $self->{description},
        $self->{quantity},
        $self->{unit},
        scalar localtime($self->{last_changed})
    );
}

None of this should be new to you, it's the same pattern we used in the Note object, but now we have changed some wording and included the quantity and unit properties in the output string.

Now if you run the test file t/02-ingredient.t, you should see that all tests pass successfully, indicating that the Ingredient object has been successfully created with the new properties and functionality.

This concludes our exploration of inheritance in Perl. We have seen how to create a subclass that inherits from a parent class, how to extend the functionality of the parent class, and how to add new properties and methods specific to the subclass. Inheritance is a powerful feature that allows us to build on existing code, making it easier to maintain and extend our applications.

We could continue to extend the Ingredient object further, for example by adding methods to convert between different units or to calculate the total cost of an ingredient based on its quantity and price per unit. We could also go further and create an Recipe object that also inherited from Note but used Ingredient objects to represent the ingredients in a recipe. However, I will let you use your own imagination on how you would implement that.

In the next post, we will move onto file handles. We will explore the different modes of file handling, how to read from and write to files, and how to handle errors when working with files. This will be an important step in building more complex applications that need to persist data to disk.

Object-Oriented Programming (OOP) is a widely used programming paradigm that enables the creation of objects that encapsulate both data and behaviour. These objects can represent virtually anything you can imagine, there are no strict limits on what you can create. It's all about how you choose to structure your code.

By encapsulating related data and behaviour, objects promote cleaner, more organised, and maintainable code. A key feature of object orientation also is inheritance, which allows you to define new classes based on existing ones, enabling code reuse and extension of functionality.

When used correctly, objects are a powerful tool for writing robust and scalable software. In this post, we’ll explore how to create and work with objects in Perl, where object orientation is a core part of the language.

In Perl, object orientation is implemented using packages. A package is a namespace that allows you to group related code together. You can create a package by using the package keyword followed by the name of the package.

We have created a package before but used it functionally by creating an exporter, to turn a package into an object we need to simply define a constructor method that will bless a reference into the package. The bless function associates an object with a class, which is represented by a package. It is that simple.

In Perl the constructor method is usually called new, but you can name it anything you want. The new method is responsible for creating a new object and initialising its attributes.

Note how now I talk about functions as methods, this is because in object orientation, functions that are associated with a class are called methods. Methods are just like regular functions, but they are called on an object and can access the object's attributes. This all works transparently in Perl, so you can use the same syntax as you would for a regular function (by name). The only difference is that you need to call the method on an object, which is done using the arrow operator ->.

I will also use the term accessor to refer to methods that get or set attributes of an object. Accessors are a common pattern in object-oriented programming, and they allow you to encapsulate the access to an object's attributes. An attribute is a variable that is associated with an object. In Perl, attributes are usually stored in a hash reference you bless, which allows you to easily add or remove them as needed. Although this is not always the case and understand also an object does not need to be a hash internally it can be any scalar reference for example an array. You would take a different approach to accessors in that case.

Today we will start simple and create a object that represents a note. The note will have a title, content, and a last_changed time. We will create a constructor method that will initialise these attributes and a method that will return the note's information as a string. We will also create accessor methods that will allow us to change the note's title and content triggering an update of the last_changed time. To achieve this we will use only core Perl, so no need to install any modules.

First, we will create a new distribution useing the Module::Starter module. This will create a new directory with the necessary files to start a new Perl module. We will call our module Note.

module-starter --module="Note" --author="Your Name" --email="your email"

With that done, we can test the module is setup correctly by running the following command:

cd Note
prove -lv t/

This will run the tests in the t/ directory and show the output. If everything is set up correctly, you should see a message saying that all tests passed. Now with the basic structure in place, we can write a test to plan our object. We will create a test file in the t/ directory called 01-note.t. This file will contain the tests for our Note module. We will do this progressively first we will simply test instantiating the object.

use Test::More;

use_ok('Note');
my $note = Note->new();
isa_ok($note, 'Note', 'Created a Note object');

done_testing();

Next, we will implement the code needed to pass the test. open the lib/Note.pm and replace the function1 definition with the following:

=head2 new

Instantiate a new Note object

    my $note = Note->new(%args);

=cut

sub new {
    my ($pkg, %args) = @_;
    bless \%args, $pkg;
}

Now we can run the test again to see if it passes:

prove -lv t/01-note.t

It should pass and that is how simple it is to create an basic object in Perl. Now for our example it is a little more complex, we want to have a title, content and a last modified time which is dynamically calculated. We should add validation to ensure that the title and content are strings when instantiating the object. We should also set the last modified time to the current time when the object is created. Lets first extend our test for our new functionality, add this above the done_testing line in t/01-note.t:

$note = Note->new(title => 'Test Note', description => 'This is a test note');
is($note->{title}, 'Test Note', 'Title is set correctly');
is($note->{description}, 'This is a test note', 'Description is set correctly');
like($note->{last_changed}, qr/\d+/, 'last_changed is set to an epoch');
eval {
    Note->new(title => { invalid => 'title' }, description => 'This is a test note');
};
like($@, qr/title must be a string/, 'title validation works');
eval {
    Note->new(title => 'Test Note', description => { invalid => 'description' });
};
like($@, qr/description must be a string/, 'description validation works');

As you can see we are accessing the attributes directly using the hash reference syntax. If you run the test you will see the first two tests pass but the rest fail. To implement the functionality we will modify the new method in lib/Note.pm to look like this:

sub new {
    my ($pkg, %args) = @_;
    for my $key (qw/title description/) {
         die "$key must be a string" if ref $args{$key};
    }
    $args{last_changed} = time;
    bless \%args, $pkg;
}

With this change, we are checking that the title and description are strings and setting the last_changed to the current time. Now if you run the test again, it should pass all tests. Undef also passes the validation, this is expected behaviour as we have a test for instantiating the object without any arguments. the last_changed attribute is always set to the current epoch time, this is a common way to represent time in programming, we will then use this later to convert to a human readable format via our accessor.

Next lets write the accessor methods for the title, description, and last_changed attributes. We will do one at a time, starting with the title method. First we will add a test for the title accessor in t/01-note.t our title accessor will be a simple getter and setter. Add the following test after the previous tests:

is($note->title, 'Test Note', 'note accessor title getter works');
is($note->title('Updated Note'), 'Updated Note', 'note accessor title setter works');
is($note->title, 'Updated Note', 'note accessor title getter works after update');

Now we will implement the title accessor in lib/Note.pm. Add the following code replacing the function2 definition:

=head2 title

Accessor to get and set title attribute

        $note->title()

=cut

sub title {
        my ($self, $title) = @_;
        if (defined $title && ! ref $title) {
                $self->{title} = $title;
                $self->{last_changed} = time;
        }
        return $self->{title};
}

If you run the test again, it should pass the tests for the title accessor. Next we will implement the description accessor in a similar way. Add the following test after the previous tests in t/01-note.t:

is($note->description, 'This is a test note', 'note accessor description getter works');
is($note->description('This is an updated test note'), 'This is an updated test note.', 'note accessor description setter works');
is($note->description, 'This is an updated test note', 'note accessor description getter works after update');

We will implement the description accessor in lib/Note.pm. Add the following code after the title accessor:

=head2 description

Accessor to get and set description attribute

        $note->description($description)

=cut

sub description {
        my ($self, $description) = @_;
        if (defined $description && ! ref $description) {
                $self->{description} = $description;
                $self->{last_changed} = time;
        }
        return $self->{description};
}

Now if you run the test again, it should pass the tests for the description accessor. Next we will implement the last_changed accessor. This should only be a getter and should return a user friendly formatted string of the epoch time. Add the following test after the previous tests in t/01-note.t:

like($note->last_changed, qr/\w{3}\s+\w{3}\s+\d{1,2}\s+\d{1,2}\:\d{2}\:\d{2}\s+\d{4}/, 'note accessor last_changed returns a formatted string');

The regular expression checks that the last changed time is in the format of a human-readable date (e.g., "Mon Jun 9 20:42:45 2025"). This will ensure that the last_changed accessor returns a formatted string. We can't check the exact time as that will change each time our script runs, there are ways of 'mocking' time but that is for another lesson. Next we will implement the last_changed accessor in lib/Note.pm. Add the following code after the description accessor:

=head2 last_changed

Accessor to get last_changed attribute, returns the epoch in localtime format.

        $note->last_changed

=cut

sub last_changed {
        my ($self) = @_;
        return scalar localtime($self->{last_changed});
}

This accessor will return a formatted string of the epoch time in localtime format (Mon Jun 9 20:42:45 2025). The localtime function is a core function that can be used to convert an epoch time to a human-readable format. Now if you run the test again, it should pass the tests for the last_changed accessor.

Finally, we will implement the info method that will return a string with the note's information. Add the following test after the previous tests in t/01-note.t:

like($note->info, qr/Note: Updated Note, Description: This is an updated test note, Last Changed: \w{3}\s+\w{3}\s+\d{1,2}\s+\d{1,2}:\d{2}:\d{2}\s+\d{4}/, 'info method returns correct string');

To implement the info method, add the following code after the last_changed accessor in lib/Note.pm:

=head2 info

Method that stringifys the details of the note.

        $note->info;

=cut

sub info {
        my ($self) = @_;
        return sprintf("Note: %s, Description: %s, Last Changed: %s", 
            $self->title // "", $self->description // "", $self->last_changed);
}

We are using a new function sprintf to format the string with the note's title, description, and last changed time. sprintf is a core function that allows you to format strings using patterns, the most simple of patterns is %s which will be replaced by the string value of the variable passed to it. We are passing 3 arguments to match the three placeholders title, description and last_changed. We use the // defined or operator for title and description and default them to strings because otherwise sprintf will warn with a message around undefined values if we were to call the method with an object not instantiated with params.

Now if you run your tests again all should pass and you've just fully implemented a Note object in Perl. To finish the module you should update the SYNOPSIS with some documentation so you remember in the future how the Note object should work.

=head1 SYNOPSIS

    use Note;

    my $note = Note->new(
        title => 'My Note',
        description => 'My first note description',
    );

    $note->info; # Returns a string with the note's information

    $note->title; # Returns the title of the note
    $note->description; # Returns the description of the note
    $note->last_changed; # Returns the last changed time in a formatted string

    $note->title('Updated Note'); # Updates the title of the note
    $note->description('Updated description'); # Updates the description of the note

=cut

I hope you found this post useful in understanding how to create and use objects in Perl. Object orientation is a powerful paradigm that can help you write cleaner and more maintainable code. If you have any questions or suggestions, feel free to leave a comment below. Next time we will look at inheritance in Perl and how to create a object that inherits from the Note object we created today.