Parham has asked for the wisdom of the Perl Monks concerning the following question:
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 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: 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:
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 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, Join the Perlmonks Setiathome Group or just click on the the link and check out our stats. | [reply] [d/l] [select] |
by Anonymous Monk on Feb 03, 2002 at 20:41 UTC | |
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. | [reply] |
by Ovid (Cardinal) on Feb 03, 2002 at 21:00 UTC | |
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, Join the Perlmonks Setiathome Group or just click on the the link and check out our stats. | [reply] |
(jeffa) Re: OOP
by jeffa (Bishop) on Feb 03, 2002 at 18:01 UTC | |
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: 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) | [reply] |
Re: OOP
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.
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... | [reply] |
Re: OOP
by dreadpiratepeter (Priest) on Feb 03, 2002 at 17:11 UTC | |
A great book by a man much smarter than this bear of little brain. -pete Entropy is not what is used to be. | [reply] |
Re: OOP
by trs80 (Priest) on Feb 03, 2002 at 17:54 UTC | |
I would suggest you read the Camel (Programming Perl) OOP sections. I recently reread it and found lots of useful information. | [reply] |
Re: OOP
by Parham (Friar) on Feb 03, 2002 at 21:24 UTC | |
The main reason's why i don't use cgi.pm... file uploading: It's ridiculously the simple way out for beginners... i chuckle when i see upload engines made with cgi.pm because it involves no actual parsing of code. If you look at any perl directory (hotscripts.com, perlarchive.com, cgi-resources.com), anything related to file uploading uses cgi.pm. It bothered me to see all programs which root back to the same place. Until i fully understand how cgi.pm (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 cgi.pm 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 cgi.pm 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 cgi.pm" 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. | [reply] |
by chromatic (Archbishop) on Feb 03, 2002 at 23:16 UTC | |
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. | [reply] |
by CharlesClarkson (Curate) on Feb 03, 2002 at 23:39 UTC | |
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. | [reply] |
by Matts (Deacon) on Feb 04, 2002 at 07:56 UTC | |
by tilly (Archbishop) on Feb 03, 2002 at 22:48 UTC | |
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?.) | [reply] |
by BazB (Priest) on Feb 03, 2002 at 21:44 UTC | |
[reply] | |
by jryan (Vicar) on Feb 04, 2002 at 07:46 UTC | |
| [reply] |
Re: OOP
by Parham (Friar) on Feb 04, 2002 at 23:24 UTC | |
So anyone looking for an apprentice to teach about perl ;) (don't take as a joke if you are) | [reply] |
by dragonchild (Archbishop) on Feb 11, 2002 at 13:50 UTC | |
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. :-) ------ Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] |