I'm glad you were able to see a benefit in the concept of object oriented programming in Perl. I could never do what I do, or do it as fast if I didn't have such great tools like which Perl offers us in the way of its support for OO. As a follow up to my previous message, and as a bit of help to those who would like to know more, I put together some of my thoughts on the subject tonight. I can clearly remember how scary this whole concept seemed to me just months ago. With a bit of reading and practice I was able to discover what makes me love Perl the way I do. I discovered the incredible benefits of using an Object Oriented programming paradigm to build re-usable, scalable code. Reading your last response reminded me of the questions I had as I first started my research. Maybe this Q and A type of tutorial will be just the thing to clear up some otherwise muddy waters which I think we all face when learning about OO in Perl. "A quick and easy intrOO" Wednesday, October 03, 2001 Copyright Tommy Butler, 2001 Re-distributable under GNU artistic liscence [Q] How do I import functions in external files to my script? [A] Well the truth is, you don't really want to import your code as much as you'd like to just have access to it with some kind of pointer. (hence, the OO syntax of the arrow '->') This helps prevent naming conflicts caused if you have a variable with the same name in both your module and in your script. Perl keeps each of them seperated by wrapping up your module into its own 'package' or 'namespace'. When you use() a module, what you are doing is creating a package of all the code in your external code library. Perl compiles all that code into super-fast Perl byte codes before your script is even run. That well packaged chunk of code that Perl just optimized for you is called a 'class' [Dum-dum-duuuuuum!] Yes, a very generic word for what most people would just call "a bunch of code stuffed into a ball that you can't mess with." [Q] But hey! How can I do anything if Perl just encapsulated my code library in that package-thingy? I made it didn't I? Give it back! [A] Easy, easy. Don't get all worked up just yet. You see, when you ask Perl to gather up your code libraries into a class, Perl lets you use a reference to 'objects' or 'instances' that you make from the original code package. If you've ever used JavaScript in your web pages, you can think of the reference concept it like the JavaScript DOM, or document "object" model. In JavaScript if you want to manipulate something in your page, like an image or form field for example, you have to tell JavaScript where to get it by providing a reference to that object. Ever done something like this? formfieldtype = document.forms[0].elements[5].type; // should be something like 'text' 'check box', 'undefined', etc... alert(formfieldtype); Well, it's the same with Perl. If you want to get access to all those yummy little routines you've put together, you have to tell Perl where to find them. Those routines which we often call 'functions' or 'subroutines' in procedural programming are called 'object methods' in object oriented programming. [Q] Why call them 'methods'? That sounds weird. [A] I know, it's kinda different huh? But who cares, it just makes it more easy to communicate with our fellow nerds about the stuff we're working on if we all use the same lingo. So 'methods' it is. On the other hand, it makes a lot of sense that the variables and other things which aren't subroutines in your module are called 'object attributes'. You define these when you ask Perl to make an instance of your code, or as we prefer to say, an 'object'. Now that's more like it, huh? It makes sense to the rest of us that this glorified thingy we're calling an object would have certain characteristics. Each object you make is unique, and not all objects are created equal. [Q] Wha? You losing me here. A little clarification please. [A] No problem. To understand what I'm taking about in saying that each object which Perl makes out of your code library is different, you have to know about a very special little bit of OO magic. [Q] Ooooooooooo! Cool. What is it, tell me, tell me, WHATISIT?!? [A] Well, since we have all these other cool words about OO to use now, how about another one? The magic term of the day then is: 'constructor method' Very good. You see, this 'constructor method' is a special 'subroutine' that every one of your modules has to have in order to work. In other words, it's like the magic spell that conjures up a new object every time you ask Perl to make one for you. Every time you do that, the code in your object constructor method gets run, and Perl makes the new object for you BASED ON THE ARGUMENTS OR PARAMETERS YOU PASSED TO THE CONSTRUCTOR METHOD. Since you can pass different arguments or parameters to your constructor method each time, each one of your objects will be unique. Some might be similar, but still each one is special and Perl will keep track of them all for you as long as you have a *REFERENCE* to them. Otherwise, they are disgarded to save system memory for new ones. [Q] Ok, how about an example then. Make me an object, and show me how to point at it so I can get to my favorite routines! How do I get a reference to the object you're making? [A] You get that refernce handed to you from Perl when you call that lovely little constructor method. Great huh? It's probably starting to make more sense why their called 'constructor methods' now. It's because that magical method lets you make new objects, and returns a refernce or 'pointer' to that object. By using that pointer, you get access to all of that object's methods and attributes. Let's try it out. We'll now make a new object for ourselves by calling its constructor method. Most people name the constructor method in their modules 'new', or sub new {...} as a matter of convention. And you should too, in case your buddies want to use your module, they'll expect that you called your constructor method 'new' instead of sub conjure_forth_from_the_eternal_void_I_adjure_thee {...} And even though that would work, it's an awful lot to type every time you need a new object, and that sucks. ;o) Ok, now that we know this, let's use a module we all know and love! use CGI; Ah, yes. Now don't you instantly feel better about yourself? You just got Perl to compile all of the code in CGI.pm into a nice library of re-useable routines. Now it's time to ask Perl to make us one of those groovy CGI objects by calling it's constructor method. Or in other words, now that we have use()'d the CGI module, it's time to start making little CGI objects that will do all of the hard work for us without making us get our hands all dirty. When we call the constructor, remember that it's gonna send back a reference to the object it makes -- so assign it to a variable (a scalar generally) so you don't lose it. my($cgi_object) = CGI->new(); ...or you can try out passing arguments to the CGI constructor too. CGI.pm lets us do that in lots of ways. You can read its docs for more info, but for now, we'll just do it like this: # tell CGI we want it to give us access to all of its routines, # instead of just the ones that are exported by default (yeah, you # can make your modules do that too.) my($arguments) = qw(:all); my($cgi_object) = CGI->new($arguments); That's not the only way you can do it though. I like to make my modules take hash-style argument lists to make it easier to remember and sort out what argument is what, and so forth. Most of the time, my calls to the constructor method of my modules look something like this: use Mailer; my($mailer) = Mailer->new( 'mode' => 'debug', 'verbose' => 1, 'log_errors' => 1, 'sendmail' => '/usr/lib/sendmail', 'admin' => 'support@atrixnet.com' ); [Q] You mean that's it? That's easy! Way cool. Ok, now show me how to get to some of the routines and stuff in that CGI object you made a second ago. [A] Yes, it's just that easy. That's why we LOOve it. Now to get your hands on the things in CGI.pm which you want to use, use the pointer you saved to tell Perl where to look first, then finish the call to the routine or CGI object method of your choice by appending an arrow operator '->' to your object reference and placing the method name after it. # get the visitor's name from the appropriate # field value entered in an HTML form my($name) = $cgi->param('name'); # get the username field value entered in an HTML form my($username) = $cgi->param('username'); # and the password which your visitor typed... my($password) = $cgi->param('password'); Or let's say you want to use a method found in the Mailer object that I made a few lines up. Well, you just have to know the method you want, and call it with the arguments you choose: # send a auto-response letter to the visitor who filled out # my HTML form, to confirm that his/her account has been created. # create the message my($message) = < MESSAGE # send the email(s) $mailer->sendmsg( 'to' => $cgi->param('email'), 'from' => 'support@atrixnet.com', 'cc' => $mailer->{'admin'}, 'bcc' => 'bigboss@mycompany.com', 'subject' => 'New Web Subscription', 'content-type' => 'html format', 'message' => $message ); That's all for now. We'll cover more ground in the next tutorial if enough interest is expressed that I would spend the time to put another one together. Good luck my friends, and thank you also for the help you all give to me. - Tommy Butler, Internet Strategies, Inc. º ° º Everything is Possible. web http://istrat.com email mailto:tommy@istrat.com tel 2 1 4 . 3 9 3 . 1 0 0 0 ext207 fax 8 0 0 . 3 0 7 . 8 1 0 5 2200 North Lamar, Suite 307 º ° º Dallas, TX 75202