in reply to When to Use Object Oriented approach in Perl? (RFC)
Bottom line for me is ... I happen to find “the object-oriented approach” to be damned useful!! :-D
And here is why: “because you always know precisely where your data is!”
Q: “Exactly what piece of data is this piece of code supposed to manipulate?”
A: this
Instead of treating “executable statements” and “the data which the statements are to affect” as two separate things, the object-oriented paradigm makes things very, very easy: whenever your executable subroutines are invoked, “the piece of data that they are intended to manipulate” is implicitly known. You don’t have to monkey-around with “passing ‘the right thing,’ everytime and everywhere” to them, as procedure/function parameters that you must take care to provide “correctly.” Instead, the language itself does this for you.
“The language, itself” also shoulders more of the burden of determining whether-or-not these subroutines are “the right subroutines to call” in any particular situation. Instead of throwing that burden entirely upon you, as the application-programmer, the language bears much of it, through a clearly-defined mechanism of classes and inheritance rules which are easy to understand ... and to exploit.
“Damned useful,” as I said earlier, because it makes my chore easier.
Now, is there an equally-pragmatic down side? You bet there is! This crops up whenever you look at a particular bit of source-code ... and you simply can’t tell exactly what it’s gonna do ... and it actually makes a difference. (Example: you’re chasing-down a nasty bug, and you run into a fork in the road, and you cannot tell which direction the rabbit might have gone.)