Forum Moderators: coopster & phranque

Message Too Old, No Replies

Quick Tip: Perl Packages

Using them to re-use common coding

         

sugarkane

9:50 pm on Mar 1, 2001 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



If you have a piece of standard code that you use in a large amount of pages, you can store it in a seperate file and call it from wherever you need it.

Example:

Create a file called foo.pm in your script directory containing:


package foo;

sub bar {
my ($firstname, $surname) = @_;
print "$firstname $surname\n";
}

1;


The code you want to execute should be put in a subroutine, as in 'bar' above. You can have as many subroutines as you want, but the file should always start with 'package your_package_name;' and end with '1;'

The external code is called from your main script by telling Perl once at the start of the script that you want to 'use' the new package, and then using the syntax


your_package_name::subroutine_name("parameter1","parameter2","etc");

to actually execute the code. An example for the above package would be

#!/usr/bin/perl

use foo;
foo::bar("John","Smith");
exit;


This would simply print "John Smith", having passed the parameters 'John' and 'Smith', which is pretty pointless in itself, but things get more interesting as the code gets more complex.

For instance, I use this technique all the time to generate navigation bars. I pass the name of the calling page to the package, which uses it to generate the navbar but with the current page highlighted on it in some way. The benefit is that you only have a single piece of navbar code to maintain, and any changes you make in it will affect the whole site. (Cascading NavBars anyone?)

You could also use it to generate a standard page footer, but with page-specific taglines at the bottom, or to generate whole <head> sections of HTML with the one command passing the title, kw and desc as parameters.

han solo

6:40 pm on Mar 2, 2001 (gmt 0)



where you looking over my shoulder on the train yesterday?

I was reading "Programming Perl" by O'Reilly, and one of the things I was reading was the section on packages, classes, and object oriented programming.

Must say, these code snippets are great!!! I'm not actually into coding my own work (yet), but getting there. And having these things posted into the forums is fantastic!!!!

Thank you thank you thank you, when I get around to actually coding, I know I'm good posting errors, because there is so much talent here for things like this.

Cheers,

Han Solo

mivox

7:21 pm on Mar 2, 2001 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Indeed, once I start really working with Perl beyond editing the HTML output of an existing script, I will set up a shrine on top of my monitor and dedicate it to sugarkane.

sugarkane

9:22 am on Mar 3, 2001 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



mivox - LOL!

han - glad to be of service, looking forward to your error reports ;)

Brett_Tabke

12:24 pm on Mar 3, 2001 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



What do you find in the difference between speed of perl module compilation and usage, vs a stock "require"?

sugarkane

6:48 pm on Mar 3, 2001 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I've not looked into it to be honest, Brett. I use 'use' purely because I always have done and it's become automatic. I might have a play over the next few days and report back.

Incidentally, for people interested in PHP, there is the 'include' command which does the same job.


<? include("myfile.php"); ?>

There doesn't seem to be a way of explicitly passing parameters, but any variables you set previous to the include will be used in the included code.

Brett_Tabke

9:42 am on Aug 24, 2001 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



The big speed difference is that USE compiles the code at the same time as the main script. Where as, require compiles the script during run time. Therefore, if you have a large number of scripts you need access too but don't need the code on every run of the main script, require can be xyz times faster when it runs.