I write in several programming languages & have for quite some time now. Interestingly, though I sucessfully(?) have crammed several flavors of syntax into my skull that machines understand, I've never been very good at learning human languages.

Which is maybe why I love PERL so much!

The entire issue raised by this discussion thread can be answered by the first basic shibboleth of PERL:

TMTOWTDI!

There MUST ALWAYS be more than one solution to EVERY problem! You can use OOP or choose not to, and you will never be wrong, you may only be shown different paths to the solution. Are you optimizing for execution speed? In that case you most likely be better off going for the 'hack'. (Frankus' word, not mine.)

If you're feeling REALLY motivated & have too much time on your hands, then do it BOTH ways & play with Benchmark.pl & you may learn something about how PERL works under the hood.

OTOH, if you have very fast turn-around in your job, you may be more interested in the maintainability of your code. Especially if your intention is on code re-use. This this case OOP offers good guidelines for design that a trained monkey can follow when re-using your code later.

And please don't flame for for implying that the use of OOP in PERL is slow in general. I'm referring to optimizations. And I do believe in wrapping your psycho-fast routines in objects and method calls as a general design principle. But the nature of the project dictates that more than a general rule. If you have 1/2 hour to turn out a CGI, you're most likely not going to be eloquent, but rather down & dirty. If you happen to be writing full-blown applications, then you're going to need a more thought out & well planned approach & design.

Wait! This isn't a Parachute, this is a Backpack!