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 CGI.pm :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 CGI.pm 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 CGI.pm 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 CGI.pm? 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 CGI.pm:

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  }
[download]

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:

sport=basketball;sport=baseball;sport=football
[download]

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 CGI.pm. 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 CGI.pm 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.

Cheers,
Ovid

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