Toby Inkster

Maybe Path::Tiny is suitable?

I am surprised that I was not aware Time::Piece before. thanks.

Time::Piece has some XS in it, which will add some overhead for people who are new to OOP or Perl.

Real world module is usually not that friendly to learn a concept. Contrived example is ok for me as long as it runs.

I'd say it's contrived to discuss objects before constructors. It sounds like you feel constructors need to be discussed in detail before object are mentioned, but perhaps you can introduce them (ctors) briefly, i. e. just enough to provide context for the discussion of objects, before returning to them.

Sid Burn:

You didn't really need any module at all to explain classes. I would say, someone only has really understand object-orientation if he knew how to code OO in an imperative or functional style. And that is the most important thing. OO is not about shiny syntax and having "class, method, new" keywords and so on, it is about the idea of encapsulating data/state.

For example an imperative way of describing a "Person-Class". At first you think about a datastructure which data/state it should hold. Well something simple, a person just have a name and an age field. And you use a simple hash to describe it.

my $person = {
    name => 'Foo',
    age  => 10,
};

But what you want is not directly messing with the hash, because it can be error-prone. The fields always need to be the same. You probably want validation and so on. So instead of directly using a hash, you just use a function to create that structure for you. Function that creates such structures are named "constructors".

sub person_new($name, $age) {
    // Some other validation for $name and $age
    return {
        name => $name,
        age  => 10,
    };
}

Now you want to do some things with it, adding age, printing the name of a person. But instead of directly accessing the hash you write functions. Only the functions should access the internals. Why? Well it is your part to explain the whole concept of methods and why someone should do that.

sub person_hello($person) {
    // Validate if a correct $person was provided
    printf "Hello my name is %s and i am %i years old", 
        $person->{name}, 
        $person->{age};
}

sub person_add_age($person, $years) {
    // Validate that $years is a positive integer number 
    // (persons don't get younger) etc.
    $person->{age} = $person->{age} + $years
}

How to use it:

my $person = person_new("Foo", 10);
person_hello($person)
person_add_age($person, 5);

Actually you can explain everything about OO in this style. If you use good old "bless" or "Moose" nothing of any of the concepts really change. Only the syntax how to use it changes slightly.

my $person = Person->new("Foo", 10);
$person->hello();
$person->add_age(5);

But the difference in syntax should be a no-brainer. Because the whole concepts about OO and why encapsulation is good/bad, why you never should directly access the internals of the hash and instead only over methods is also valid with just pure functions.

(If you can't explain)/(If someone doesn't understand) why someone should only use person_add_age() then he will also not understand why he only should use methods and never do a "$person->{age}" directly on an blessed object.

And actually that whole concept is also how Perl's OO works. In fact you could say that Perls "bless" and "->" is just syntactic sugar.

If it is "$person->foobar" it is "$foobar" that is automagically passed as the first parameter, if you have "Person->foobar" than the string "Person" is passed as the first Parameter. So someone will directly understand why "$person->add_age(5)" gets two parameters instead of just one, the "5".

So, you don't really need any modules at all. You also can explain immutability with functions and why it is better to return something new, instead of mutate data in an hash. Or other stuff about OO.