Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things


by Parham (Friar)
on Feb 03, 2002 at 16:39 UTC ( #143074=perlquestion: print w/replies, xml ) Need Help??
Parham has asked for the wisdom of the Perl Monks concerning the following question:

I've been using perl for 2 years now and i think it's about time i take a leap of faith and try something totally new (that's how i got into perl). I don't know what OOP is all about, and i don't see how it can make anything i program any better. That's why i'm here. i have read the following documentation but did not completely understand them.
perlboot and perltoot

what makes OOP any more different than how i program right now (very linearly). Anyone have any tips or anything that'll help all of this make sense. I'm just waiting for something to click in my head.

Replies are listed 'Best First'.
(Ovid - don't use OO) Re: OOP
by Ovid (Cardinal) on Feb 03, 2002 at 18:35 UTC

    Update: I should have prefaced this entire node with "Kudos to you for wanting to expand your skills." Wanting to learn more is always a valuable asset in any profession. That being said...

    Parham says, on his homenode:

    I don't like modules and I don't use them

    I just started actually using my PerlMonks account. If you ever chat with me, you'll get to know that i'm not a big fan of modules. I always avoid them and try to do things my own way. I find that until i learn to do things on my own, modules are the simple way out. Learn to do the simple things on your own, and when you understand how to do them, then use modules.

    I even created my own upload engine just to avoid using :D

    From what you say on your homenode, the greatest strength of OO Perl is a poor fit for you: code reuse. You write in the root node to this post that you "don't see how it can make anything [you] program any better". Think, for a moment, about the module that you refuse to use. I have hundreds of programs at work that are dependant on that module. It's in one spot and I never have to worry about duplicating its functionality. Now, you may claim that I took the simple way out, but in the course of using for years, I've gotten to the point where I feel I have a better grasp of CGI and HTTP than most. Further, I have an ethical obligation to provide to my customers the best quality software at the lowest possible cost. If that means using someone else's freely available software, so be it.

    Show me how you connect to databases. Do you write your own cryptographic schemes to avoid the tried and true ones that are readily available? And while we're at it, why don't you post your alternative to If it's really good, why not send it to the CPAN after peer review? If it's bad, at least you'll know. Remember, what I said about "ethical obligation"? At times that means swallowing one's pride. If you still refuse, after this, to use modules, why even bother with OO?

    Back to your question at hand. Benefits of OO:

    • Code reuse
    • Data hiding
    • Standard interface shields user from implementation changes
    • Learning the benefits of modularity and encapsulation will improve your current coding style
    • Fatter paychecks :)
    • Many more benefits that should be experienced to be appreciated

    I don't like sounding really harsh in a post and I fear I may have done that here, but I am dead serious. If you do work for others, you do have an ethical obligation. That doesn't mean that you have to use the modules you find on the CPAN, but you should have a stronger case than "I don't like 'em". Further, while you claim that modules are the "simple way out", I typically see people struggle with modules and then finally "get it". Their productivity improves, their code quality improves and, this is the fun part ... they find that it's not the simple way out because they are still learning.

    Oh, I just saw your scratchpad! You claim that the following code is just as effective as

    001 if ($ENV{'REQUEST_METHOD'} eq "POST") { 002 read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}); 003 } else { 004 $buffer = $ENV{'QUERY_STRING'}; 005 } 006 007 @pairs = split(/&/, $buffer); 008 foreach $pair (@pairs) { 009 ($name, $value) = split(/=/, $pair); 010 $value =~ tr/+/ /; 011 $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/ +eg; 012 $FORM{$name} = $value; 013 }

    No, it's not. You have all of the bugs traditionally associated with hand-rolled alternatives. Let's go through this so you can see some of the problems.

    First of all, you are clearly not using strict. See 'use strict' is not Perl. I also suspect you are not using warnings. This is not good. Some people can get away with this, but from what I see with your code, you are not one of them.

    Line 002: do you think that the contents of $buffer are the same length as $ENV{'CONTENT_LENGTH'}? How will you know, since you didn't test for this? Someone can stop a particularly large POST and you'll have data corruption. Learn the basics of validating data.

    Line 004: is this for the GET method? It will also kick off if someone calls your script with HEAD, PUT, TRACE, or any of a number of other methods. Will this cause a problem or not? Learn HTTP.

    Line 007: Whups! Did you know that the semi-colon is the HTML 4.0 recommendation|preferred separator for query strings? Your code will break with any user agent that handles this properly. Learn W3C standards.

    Line 012: This is unfortunate. Names are allowed to have multiple values. Your code will always overwrite old values. The following query string is quite legal, but your code won't handle it:


    So, this means that you also need to learn the CGI protocol.

    I also have to assume that this is not the upload engine that you refer to, since it does not handle file uploads.

    You also wrote that this code is just as effective as In addition to not correctly dealing with the issues above, it can't handle headers, cookies, HTML generation, or any of many, many other things that just does. See use CGI or die; for more information.

    Once again, I don't mean to sound harsh, but I do mean to be blunt. When you can appreciate the virtues of code reuse (even if this code is not your own), then, and only then, will venturing into object oriented Perl be a good fit for you.

    I realize that this post may make you feel bad, but there's a bright side to all of this: every mistake is the opportunity to learn. Trust me, when I started learning Perl, I was awful. Oh, I could put together just about anything I was asked to do and my code did what it was supposed to do, but in learning Perl and hanging out at Perlmonks, I started to get beyond hacking Perl and learning how to be a better programmer, regardless of the language used.

    Keep coming back and asking us questions. We'll be happy to help and make your code and your overall programming better.


    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        I did not give your post a ++ because you posted as Anonymous. However, you have a great point. In the event that you posted Anonymously because you were concerned about downvotes, you needn't worry about that from me. I have, on many occassions, given someone a ++ even though they have disagreed with me.

        One of my greatest sources of personal shame is my review of Perl and CGI for the World Wide Web. In this post, Dominus rightly takes me to task for my "excessively snide" review (clintp made similar points). I have started on a review of the second edition of the book and the first thing I have done is take the time to point out Elizabeth Castro's strong points. One day, I'll get around to finishing the review. Until that time, thanks for reminding me that there are better ways to win people over.


        Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

(jeffa) Re: OOP
by jeffa (Bishop) on Feb 03, 2002 at 18:01 UTC
    Your question could fill an entire book, in fact, it has filled many books! While i consider TheDamian's OO Perl the BEST book out there on the subject for OO Perl, i don't think i could honestly recommend it to you right now, simply because if you didn't get perlboot or perltoot - TheDamian's book might send you screaming.

    First, i don't recommend learning OOP for the first time with Perl (and don't get me wrong - i love OO Perl). The reason is because Perl was not designed as an OO language in the first place. Java has a good model that is very easy to comprehend - Perl is flexible and as such, easier to get wrong.

    Second, i don't feel that OO is the right solution for every problem out there. There is a good reason that Perl was not designed as an OO language in the first place - you have to design a framework first. Personally, i don't like having to do this for every single little utility script that i write, especially the ones that are used once and 'thrown away'.

    So what is OOP all about? According to TheDamian (from the afore mentioned book), benefits might be:

    1. simpler analysis methods
    2. domain-oriented approach to design
    3. cleaner and more compact code
    4. more robust implementations
    5. greater code modularity
    6. easier debugging
    7. more comprehensible interfaces
    8. better abstraction of software components
    9. less namespace pollution
    10. greater code reusability
    11. scalability of software
    If you get the idea that OO is for LARGE projects that involve TEAMS of programmers, then you are right. But you as a single programmer on a small app can still benefit, mainly with items 3,5,6, and 10 (just my opinions of course).

    I started learning OO back in 1996 and i consider myself a little bit above an OO novice, just to give you perspective. It takes a bit of time before you get that 'OO click'. Go back and re-read perltoot and perlboot, work through the examples, eventually you will get it. If you have some code that you wrote that you feel might benefit from being 'ported' to OO, post it and one of us will gladly show you how to do so. Examples are the best learning tool, especially since there are so many buzz words that float around the OO domain.


    (the triplet paradiddle with high-hat)
by Biker (Priest) on Feb 03, 2002 at 17:48 UTC

    If you're new to the concept, you should probably start by reading up on OOD. That's Object Oriented Design. Pushing it far (and hard), I'd say that OOP is just syntax, while OOD is problem definition and problem solving.

    Let me give you just a few ideas of what the benefits from OOD/OOP may be:

    • You want to deal with a collection of data that 'belongs together', like dealing with everything that makes up a subscriber. That may be name, address and phone number. Well, put them together in one object and deal with them as 'subscriber'.
    • Now you have a simple way to deal with a collection of many subscribers. (By instantiating many subscribers and putting the handles to all those in an array, for example).
    • You may inherit from the definition of a subscriber to create a specialized list subscriber, thereby automatically have all the base information from 'subscriber' already given (inherited) and just adding the specifics for the list subscriber to your object.
    Be prepared though, that there's a lot of new lingo that comes with OOD/OOP. In Perl, you may as usual choose how far you want to go with that as with anything else. TMTOWTDI. ;-)

    You should probably read up on concepts like: Classes, Objects, Methods and Inheritance before you start learning how to program object oriented.

    "Livet är hårt" sa bonden.
    "Grymt" sa grisen...

by dreadpiratepeter (Priest) on Feb 03, 2002 at 17:11 UTC
    For starters, I would look at the most excellent 'Object Oriented Perl', by theDamian, Damian Conway.
    A great book by a man much smarter than this bear of little brain.

    Entropy is not what is used to be.
by trs80 (Priest) on Feb 03, 2002 at 17:54 UTC
    Using OOP improves the way I think about the code I am producing. I found it helps abstract ideas into more durable code. When I started using OOP I moved existing functions into a class and restructured them to "think" like methods and this helped show a clearer path to combining existing code. I find it also helps when you go to write the program that does the task at hand (actual end use of the class) because I am able to focus on the task/result not the code at that point.

    I would suggest you read the Camel (Programming Perl) OOP sections. I recently reread it and found lots of useful information.
by Parham (Friar) on Feb 03, 2002 at 21:24 UTC
    I'll admit that my approach to programming in perl may be wrong, but i like challenges, however stupid they may make me. All of your points were 100% valid Ovid, and i'll agree with you to a certain extent. I will admit that i do use certain modules, ie DBI and the DBD modules... Even though i avoid, i do not avoid use strict;, -w, and -t. I'm not all that stupid ya know ;).

    The main reason's why i don't use

    file uploading: It's ridiculously the simple way out for beginners... i chuckle when i see upload engines made with because it involves no actual parsing of code. If you look at any perl directory (,,, anything related to file uploading uses It bothered me to see all programs which root back to the same place. Until i fully understand how (just one of many modules) works, i'll try to work my own way out of situations not because i'm full of pride, but just because it wouldn't be fair to myself.

    Parsing query strings: i will sooner or later use for parsing just because it is the smarter way to deal with situations. For my scripts right now, i think that the code provided suits me well. I also don't use cuz that has OOP in it (going back and forth here), so that's why i want to get a good grep() on OOP. I shouldn't have said "as effective as" though.. sorry

    I would love to get u'r opinion on my upload engine though Ovid. I know i'll get more people telling me i should use modules, and i will, when i learn to do what they do for the most part.

    Forgot to thank everyone for their comments on OOP.. thanx :D. Thanks for the lil' talk Ovid.
      Until i fully understand how (just one of many modules) works, i'll try to work my own way out of situations

      I agree with Ovid and tilly, but I'm not going to debate this point. Follow the links if you'd like to get my position.

      As a fellow programmer, a Saint here, a Perl 5 Porter, and an author, I have a request of you. Please do not share this code with anyone else. If you do feel compelled to share it, or to use it on the public Internet, please put up strong disclaimers that say, "Do not use this code. I don't know what I'm doing. This is not representative of the Perl language as a whole, good Perl programming practices, modules on the CPAN, or more experienced Perl programmers. Any and all errors and flaws in this code are my own learning experiences, and should not reflect badly upon anyone but myself."

      I don't mean this to sound harsh or flippant. I'd just like to stem the tide of bad code being distributed and re-used. If you want to reinvent wheels for your own education, fine. Please don't make things harder for the rest of us who have to deal with bad code on a daily basis.

      Thank you.

      Update: Removed some punctuation that affected the tone for the worse.

        Oh, if only someone had told Matt that so many years ago. What a different place the internet might be.

        Charles K. Clarkson
        Clarkson Energy Homes, Inc.
      This is a point of view that comes up every so often. While the idea of only using what you understand seems reasonable, actually it is seriously wrong for trivial reasons. If you think that you are actually doing this, then the only question is where you start lying to yourself. Because I guarantee you that that you are using stuff that you don't understand all of the time. You can't help doing so if you are getting anything useful done at all, from "Hello, World" on up.

      For an instance of a past conversation like this see Modules Vs. Manual Coding. I entered that thread fairly late at Re (tilly) 3: Modules Vs. Manual Coding. (A response that was somewhat heated for reasons that ichimunki stated.)

      About your code as presented, suppose that you write all of your scripts like this. Suppose that some day you have a form that managed to get over 2K of data in it. Your code would break, you would have no idea why it was broken, and if you were told why you would have no easy way to fix it. If you used CGI you would be able to change one word in one place and it all would work.

      For this and other reasons, I strongly recommend that instead of trying the futile path of understanding every single thing you ever use, learn to leverage effectively off of the work of others. (Which eventually leads to the attitudes I suggest at Re (tilly) 1: What if you are not a genius?.)

      Parham said:

      I also don't use cuz that has OOP in it.


      CGI also has a functional interface.
      If you don't feel comfortable using the OO interface, the functional interface is there to be used. (See the CGI docs).



      Here is something to consider, from the emminent Dominus: Re: Perl 5.6.1.
by Parham (Friar) on Feb 04, 2002 at 23:24 UTC
    As stupid as it may seem now... i have taken all of your suggestions into a lot of consideration, read links you posted, and well... you are right, i shouldn't reinvent the wheel. I don't remember which post i read this from, but "if it's distributed with perl, it's just as good to use as the functions built into the core of perl". My obvious followup question would be "why isn't it programmed into core perl then?" which i don't think anyone wants to get into. So i'll admit defeat, and thank anyone who even remotely posted about the stupidity which i showed.

    So anyone looking for an apprentice to teach about perl ;) (don't take as a joke if you are)
      For most of us, "core perl" includes silly things like CGI, DBI, strict, as well as 10,000 other modules that get distributed with Perl. I would NEVER take a job programming in an environment where I had to roll all of my own stuff. It's ridiculous. It would be like going into a C++ shop and being told you couldn't use the String class. What's the point?!?

      Many of those modules you're balking at using actually change how "core perl" works. Don't ask me how - I'm not that smart. But, I know they do.

      In addition, they work. This is all I need to know. They are "black boxes" to me. I push button X and light Y turns on. I let go and it turns off. I can repeat this to my heart's content. That's the point behind modular programming.

      Think of it this way - you use a computer, but I'll bet you've never designed a circuit board, transformer, keyboard, CRT, or operating system. Yet, you use them as "black boxes" all the time. Just think of a module as you would a monitor. :-)

      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://143074]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (2)
As of 2018-04-24 03:20 GMT
Find Nodes?
    Voting Booth?