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.

I don't like sounding really harsh in a post and I fear I may have done that here

Before you use a stick you should use a carrot if you want Parham to listen to your points.

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.

Cheers,
Ovid

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

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

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.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

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.

Until i fully understand how cgi.pm (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 cgi.pm cuz that has OOP in it.

TMTOWTDI.

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).

Cheers.

BazB.

Here is something to consider, from the emminent Dominus: Re: Perl 5.6.1.

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.