in reply to Make Perl an OO language

Objects are not the "end-all" cure. They help in situations where behaviors are similar yet distinct.

Until you get to about 1000 lines of code (either that you wrote, or including a library), objects are actually more harmful than helpful. That's because it'll take about 1000 lines of code before you need inheritance. And if you're not using inheritance, you really don't need objects. Data hiding is cool, but with a rich set of data structures as primitives, Perl doesn't have that "urge" to "go objects" as early.

Since 80% of the Perl applications in the world are under 100 lines (maybe even under 20 lines), it's no wonder that most Perl applications don't use objects.

Sure, learn objects for large apps. But don't make the "java" mistake, where you must learn them for every app (even though Java is a partial non-OO language as well: it's the worst of both worlds!).

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re^2: Make Perl an OO language
by Aristotle (Chancellor) on Oct 29, 2002 at 21:22 UTC

    I wouldn't say inheritance is the end-all criterion to decide whether to use OO, nor even is data hiding. I relatively often find myself using OO even when I need neither.

    I often have a bunch of functions that all deal with a specific, non-trivial data structure and only make sense in the context of this data structure. In this case I usually bundle them into a class and then use the OO syntax on the resulting objects so as to have that data structure implicitly passed around. I am not doing real OO there of course, but the syntactic sugar makes the code easier to read - sometimes dramatically so.

    See rules 2, 6, and 10 of Damian Conway's ten rules for when to use OO.

    Makeshifts last the longest.

[reply]

In Section Meditations