Judge a book by it's author

[systems]

I started to learn Perl very recently, and the only free Perl book I found was Beginning Perl by Simon Cozen.

It was a wrox book, and from what I heard (slashdot comments) wrox book are not usually good, plus Simon's picture on the cover gave me the wrong impression. (Too young)

Anyway, I was between should I risk my time reading this book, or should I risk my money and buy a famous one (mostly it would have been Learning Perl, or Programming Perl).

Anyway I decided to investigate (search) after Simon, and to my surprise he turned out to be an impressive guy.

He write frequently about Perl he wrote a second Perl book (the one you are talking about), he is responsible for maypole, which is arguably a better concept than catalyst.
why? because I think I agree with Tony Bowden that frameworks are hard. I add that open source software being free, reduce some abstractions need, because there is no single vendor to which you are afraid to be tied, don't abstract to be politically correct, I don't mind framework that are strongly couple to specific implementation and technologies like OpenACS which require aolserver and Postgresql.

And on another point I heard Sebastian that the main guy behind catalyst is a fan of multiple inherentance, and I don't like interitance in general, single or multiple.

Anyway, back to the point, Simon Cozen is ok, you can trust he has done a good job, and don't take my word look at his other work, writings.
You may also want to read this interview with him.

And finally, good luck studying

[Corion]

Honestly, I don't think you know what you're talking about.

If you think that inheritance is bad, and thus prefer Maypole over Catalyst, you show that you don't understand inheritance, as both frameworks have an incestual relationship with many Perl modules.

Simon was responsible for the initial development of Maypole but doesn't take an active part in it anymore.

I really don't get what you're aiming at with your idea of being politically correct by being more abstract, but then, maybe this is a bit outside of the scope of a question about a Perl book.

[robot_tourist]

Inheritance is an essential part of any Object Oriented Programming language. Some languages implement it better than others, some programmers implement it better than others, but I don't know of a better way (although I have been out of university for a couple of years now).

[systems]

First not all object systems implement or provide inheritance for example check snit
In my understanding inheritence serve two purposes
1. Gives you a mean to say that an object have more than one type (play more than one role, thus inheritance and multiple inheritance), this is only useful if you ever need to test an object type, which as far as I only required by static languages, and usually forwned upon in dynamic languages
2. Give a default value for the method the object inherited (unless you are inheriting from an abstract class)
I think you find can other ways to achive both requirements without inheritance. Which makes inheritance an implementation detail, a technique not a requirement.
I prefer to focus on the requirement, and consider the different ways and alternatives to achieve it.

[robot_tourist]

IMO your point number two is pretty fundamental to object orientation and is a very good one-line synopsis, you take a class and extend it by adding functionality, but keeping all the stuff you don't want to re-invent. And it gives you a nice tree to draw when you are designing your system.

Personally, I can't think of a good reason not to use inheritance.