Stefan,
From your post I understand you to mean that you've never done OO programming before, and you are wanting to learn it within Perl, not that you already understand OO and simply want to learn how to do it in Perl.
This is exactly the same boat I was in around 9 years ago as a budding Perl programmer. I had never touched OO; I thought it was some useless buzzword. I'd seen it explained slightly in some introductory CS textbooks, but never in a way that made the use apparent. :)
Perl is where I learned OO, and that has been the right place to do it. I completely disagree with those who said go learn your OO concepts elsewhere and then come learn how to do it in Perl. The authors of Perl's OO documentation are some of the world's best programmers. If you learn OO here, you will learn it as well as or better than you will learn it anywhere else.
This was exactly the case for me. Within two years of learning OO through Perl, I was designing a team project and school and everyone agreed my OO design work was spectacular, even though they had far more OO experience than me. I've received similar such validation for my OO understanding ever since, in undergraduate and graduate work, as well as in my professional career. I am today (sadly) a Java programmer (though still a Perl programmer at heart), and much of my work consists of fixing up things people have done earlier, improving the OO considerably for real, tangible benefits in maintainability, added features, and bug fixes.
Sorry; I hope it doesn't sound like I'm tooting my own horn. I'm just another Perl programmer. :) I'm just saying that if you learn OOP in the Perl world, you will not be at any disadvantage under other languages, and in fact you may very well find yourself at an advantage.
Here's a path I'd recommend; it looks similar to the path I took:
- Learn to use one or more object-oriented modules. There's no better way to wrap your head around OO than simply iusing/i somebody else's classes and objects. Trying to learn to create your own first is all wrong. The module I used was CGI.pm, but today the recommendation is to not use that module in an OO fashion. :) I believe the module I would recommend for you is DBI. (And a backend of your choice.) If you already know DBI or at least one other object-oriented module, you already have a substantial leg up!
- Now go read perlboot and perltoot from the Perl documentation. I think in my day all I had was perltoot. :) Actually I made it a point to sit down every day after lunch and read through an entire perl manpage, after about a year's Perl experience. There's a lot more to read nowadays. :) I wasn't doing this to learn OO; that was one of the side-benefits. "perldoc perl" gave a suggested reading order back then that has been immensely fleshed out since.
- After perlboot/perltoot and some playing around (probably including writing a class or two for real tasks), you can spend some time with the Damian Conway book, though this may not be necessary at that point. I have that book and have never finished it. You most likely don't need to know all the special non-standard ways of doing OO, like blessing things that aren't hashes, or making your classes be inside out or upside down or whatever else is in vogue these days. Learning all those things is good, but they are the 80% of the effort behind the last 20% of the work. So don't get bogged down this year feeling like you have to read everything professor Conway has to say; save some for when you are a wizard doing advanced experiments.
- After this, I would say, go adopt Moose and learn it. I have to say Moose has only recently caught my attention, and being a Java programmer by trade I haven't had time to build anything real with it, yet. But it really looks to me like The Way To Go, bringing in a lot of wonderful things to Perl's OO. My next object-oriented Perl code WILL be a subclass of Moose.
- After that you will be a wizard. Do what you want. Learn all the funky stuff. :)