Was sind Perl Module und welchen
Nutzen haben sie?
Installation der Module
Anwendung der Module
Verzeichnisse, in denen Perl im Default nach Modulen
sucht
Perl Module selbst schreiben /
Subroutinen und Variablen von einem Modul in das Hauptprogramm
exportieren:
a) das ganze Modul objektorientiert programmieren
b) den ganzen Pfad zu der entsprechenden Variablen
oder Subroutine angeben
c) mit dem Modul EXPORTER bestimmte Subroutinen
und Variablen exportieren
d) die zu exportierenden Subroutinen und Variablen
in den Array EXPORTER_OK eingetragen
e) Zusammenfassung
| Was sind Perl
Module und welchen Nutzen haben sie? |
|
Ohne Module wäre Perl
im Internet Umfeld weitgehend wertlos, da zentrale Probleme,
wie z. B. der Zugriff auf relationale Datenbanken nur mit
Modulen möglich ist. Es handelt sich dabei um kleine
Softwarepakete, die in Perl eingebunden werden und damit die
Leistungsfähigkeit von Perl stark erweitern.
Es gibt wohl nur noch ziemlich wenig Probleme, die nicht bereits
über Module gelöst wurden.
Unter anderem gibt es folgende Module:
Das Problem bei der Anwendung von Modulen besteht
darin, überhaupt zu wissen, ob es für das zu lösende
Problem ein Modul gibt und wo man es findet. Bei www.activestate.com sind
über 3000 Module gelistet (in alphabetischer Reihenfolge).
In der Regel haben die Module sinnvolle Namen (findfile, sendmail,
dbd:mysql, gdchart etc. ), so dass eine realistische Chance
besteht, sie zu finden. Eine andere Möglichkeit bietet
CPAN. Hier liegt eine thematische Ordnung der Module vor.
Die Module müssen in Perl eingebunden werden, bevor man
sie verwenden kann. Das geht am einfachsten mit dem perl packet
manager von activestate. Die meisten Module, die bei activestate
zum Download angeboten werden, unterstützen diesen Standard.
(Dieses Handbuch richtet sich primär an Leute, die Perl
unter Windows anwenden. Unter Unix und dessen Derivaten werden
die Module mit makefile eingebunden. Wenn man die SUSE Distribution
verwendet, erfolgt das Einbinden mit YAST.)
Beim Herunterladen eines Moduls von activestate,
erhält man einen zip file (z.B. DBI.zip). Dieser wird
dann mit einem geeigneten Programm (z. B. Winzip) "entzippt".
Eine der jetzt vorliegenden Dateien heißt: readme (liesmich).
Dieser Aufforderung zu lesen, sollte man nachkommen. Man hat
dann z. B. folgendes vor Augen:
To install this ActiveState PPM package, run the following command
in the current directory:
ppm install CGI.ppd
Activestate hält das offensichtlich für
didaktisch brillant und eigentlich ist es das auch. Das heißt,
in die Eingabeaufforderung der Dos Box "ppm install CGI.ppd"
eingeben (vorher mit cd in den Ordner mit den entzippten Dateien
gehen). Wenn die Perl Distribution von activestate installiert
ist, erscheint eine Zeitlang installing "irgendwas irgendwo"
auf dem Schirm. Danach ist das Modul installiert.
Es folgt ein Beispiel. Doch zuerst muss
das Modul date:calc installiert werden. Download
Die Installation erfolgt dann wie oben beschrieben. Unten stehendes
Skript anschließend kopieren und unter mein_name.pl im
cgi-bin Verzeichnis abspeichern. Das Skript wird dann mit http://127.0.0.1/cgi-bin/mein_name.pl
aufgerufen. Nicht vergessen vorher den HTTP Server hochfahren
(sambar, Apache, Omnihttp, Xitami ect.).
#!/usr/bin/perl $frage=$ENV{'QUERY_STRING'};
@frage=split(/&/,$frage);
foreach $i(0..$#frage)
{
@frage[$i]=~s/\+/ /g;
($key,$value)=split(/=/,$frage[$i],2);
$value=~s/%(..)/pack("c",hex($1))/ge;
if ($key eq nick)
{
$value=~s/\ /-/g;
}
$value=~s/\n/ /g; $value=~s/\"/ /g;
$Frage{$key}=$value;
}
################## ENDE BLOCK 1 ########################
($sec,$min,$hour,$mday,$mon,$year,$wday,$ydat,$isdst)=localtime();
$jahr=$year;
$monat=$mon+1;
$tag=$mday;
$jahr=$year;
if (length($year) == 2)
{
$jahr="20$year";
}
if (length($year) == 3)
{
$jahr="2$year"-100;
}
if (length($monat) == 1)
{
$monat="0$monat";
}
if(length($tag) == 1)
{
$tag="0$tag";
}
################## ENDE BLOCK 2 ########################
print "Content-type:text/html\n\n";
if ($Frage{modul} ne 1)
{
print "<html><head><title>Datum berechnen</title></head>
<body>
Heute ist der $tag.$monat.$jahr.
<form action=http://127.0.0.1/cgi-bin/datum.pl>
<input type=hidden name=modul value=1><br>
Geben Sie die Anzahl der Tage ein, die Sie zum heutigen Datum
<br>
<select name=was><option>hinzuaddieren<option>subtrahieren</select>wollen.<br>
Tage <input type=text size=4 name=tage><br>
<input type=submit value=abschicken><br>
</form></body></html>" ;
################## ENDE BLOCK 3 ########################
}
else
{
use Date::Calc qw(Add_Delta_Days);
if ($Frage{was} eq hinzuaddieren)
{
($y2,$m2,$d2)=Add_Delta_Days($jahr,$monat,$tag,$Frage{tage});
if (length($m2) == 1)
{
$m2="0$m2";
}
if(length($d2) == 1)
{
$d2="0$d2";
}
print "<html><head><title>Ergebnis</title></head><body>
Addiert man zum heutigen Datum $Frage{tage} Tage hinzu,
dann erhält man als Datum den<br> <font
color=red size=5> $d2.$m2.$y2</font></body></html>";
}
if ($Frage{was} eq subtrahieren)
{
($y2,$m2,$d2)=Add_Delta_Days($jahr,$monat,$tag,-$Frage{tage});
if (length($m2) == 1)
{
$m2="0$m2";
}
if(length($d2) == 1)
{
$d2="0$d2";
}
print "<html><head><title>Ergebnis</title></head><body>
Subtrahiert man vom heutigen Datum $Frage{tage} Tage,
dann erhält man als Datum den<br> <font
color=red size=5> $d2.$m2.$y2</font></body></html>";
}
}
Bis ENDE BLOCK 1 liest das Skript den sogenannten
QUERY_STRING aus, bzw. packt die einzelnen Elemente in einen
Associative Array.
(Perl Routine zum Auslesen des QUERY_STRING)
Die Tage, die addiert bzw. subtrahiert werden sollen stehen
jetzt in $Frage{Tage}. Das Modul, welches angestoßen
werden soll, steckt in $Frage{Modul}.
In dem Bereich bis ENDE BLOCK 2 ermitteln wir das heutige
Datum. (Details siehe: Datum
ermitteln)
Darüber hinaus muss der User noch angeben, ob zu einem
bestehenden Datum die Tage abgezählt oder hinzuaddiert
werden sollen. Dieser Wert steht in $Frage{was}. Wird das
Programm zum ersten mal aufgerufen, ist $Frage{Modul} nicht
vorhanden also ungleich 1. Folglich wird das Formular aufgebaut.
(Formulareingaben
mit Perl auswerten)
Interessant ist diese Zeile: use Date::Calc qw(Add_Delta_Days);
Mit use teilen wir Perl mit, dass wir beabsichtigen, das Modul
Calc.pm zu verwenden. Diese Zeile ist normalerweise einfacher
und sieht eher so aus: use DBI, use CGI oder use GD
etc.
Es gibt also drei Dinge zu klären.
-
Was soll das Date vor Calc?
-
Wieso wird nur Calc aufgerufen, obwohl die
Datei Calc.pm heißt? ( sie liegt in c:/perl/lib/Date/Calc.pm)
-
Woher kommt Add_Delta_Days?
Das Date erhalten wir, da das Modul Calc.pm
in einem Unterverzeichnis von c:/perl/site/lib nämlich
in Date liegt.
Folglich müssen wir Date mit angeben. Man könnte
sich jetzt fragen, wieso Perl in c:/perl/site/lib nach irgendwelchen
Modulen sucht.
Die Antwort ist einfach, es gibt bestimmte Verzeichnisse,
in denen Perl automatisch nach Modulen sucht, z.B. in c:/perl/site/lib,
c:/perl/lib oder in dem Verzeichnis, welches das Hauptskript
enthält.
Alle Verzeichnisse, in denen Perl im Default
nach Modulen sucht, stecken in dem Array @INC.
Wer sich das anschauen will, hier ein kleines Beispiel:
foreach (@INC)
{
print "Verzeichnis $_ \n";
}
Für die Ungläubigen, basteln wir jetzt
ein Minimodul, das den Sachverhalt verdeutlicht. Wir haben
das Modul:
package hello;
print "hallo du Nase";
1;
package siehe Objektorientierte
Programmierung.
Wir erstellen jetzt in einem der Default Ordner z.B. c:/perl/site/lib
einen Ordner mit dem Namen hallo. Dort speichern wir das obenstehende
Modul mit dem Namen hello.pm ab (die Datei muss so heißen
wie das Package). Dann schreiben wir ein Programm, das dieses
Modul verwendet:
use hallo::hello;
Das Programm führen wir aus. Was kommt
hier raus? hallo du Nase.
Was schließen wir daraus? Das Modul wurde aufgerufen.
Die Endung pm kann man weglassen, wenn man use verwendet.
Bleibt noch die Frage, woher kommt das Add_Delta_Days. Prinzipiell
ist Add_Delta_Days eine Subroutine, die in dem Modul Calc.pm
steckt. Diese Subroutine ist ohne weiteres in dem aufrufenden
Skript nicht sichtbar und muss exportiert werden. Machen wir
uns die Vorgänge noch mal an einem Beispiel klar. Wir
haben folgendes Modul:
package hallo::hello;
use Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(rechnen);
@EXPORT_OK = qw();
sub rechnen
{
$summe=$_[0] + $_[1];
}
1;
Aufgerufen wird dieses Modul von diesem Skript:
use hallo::hello;
print &rechnen(44,67);
Das Modul muss in irgendeinem Ordner hallo in
einem Default Pfad für Module abgespeichert werden. Ruft
man das Skript auf, erscheint 111 auf den Schirm (44+67).
Interessant ist jetzt das Modul:
use Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(rechnen);
@EXPORT_OK = qw();
Mit use Exporter rufen wir ein Modul auf, das
Variablen und Subroutinen in das aufrufende Skript exportiert.
Dieses wird dann in den Spezialarray @ISA eingetragen (Objektorientierte
Programmierung).
Variablen oder Subroutinen, die immer exportiert werden sollen,
werden in den Array @Export eingetragen.
Variablen oder Subroutinen, die nur auf Anforderung exportiert
werden sollen, landen in dem Array EXPORT_OK.
In dem Beispiel mit Date::Calc liegt der letzte Fall vor.
Zur Verdeutlichung wird dasselbe Beispiel noch mal in einer
anderen Variante dargestellt.
das Modul:
package hallo::hello;
use Exporter;
@ISA = qw(Exporter);
@EXPORT = qw();
@EXPORT_OK = qw(&rechnen);
sub rechnen
{
$summe=$_[0] + $_[1];
}
1;
das aufrufende Perl Skript:
use hallo::hello qw(&rechnen);
print &rechnen(44,67);
Was hat sich geändert? Die Subroutine "rechnen"
wird jetzt nur exportiert, wenn sie angefordert wird. Sie
wurde in den Array @EXPORT_OK eingetragen. Wir fordern sie
im aufrufenden Skript an mit der Zeile:
use hallo::hello qw(&rechnen);
Damit haben wir die gleiche Syntax wie in obigem Beispiel.
use Date::Calc qw(Add_Delta_Days);
use hallo::hello qw(&rechnen);
Man muss das alles nicht im Detail verstehen, um ein Modul
zu verwenden. Es reicht, wenn man die Syntax via paste and
copy übernimmt.
In der Zeile: ($y2,$m2,$d2)=Add_Delta_Days($jahr,$monat,$tag,$Frage{tage})
übergeben wir Add_Delta_Days (das aktuelle Datum und
die zu addierende Anzahl an Tagen) an die Funktion und erhalten
links das Datum, das sich dann einstellt. Nach einem ähnlichen
Schema können auch alle anderen Module aufgerufen werden.
Unterschiede gibt es nur noch bei den Modulen, die objektorientiert
programmiert sind. Allerdings ist die Vorgehensweise einfach
zu verstehen, wenn man sich die Objektorientierte
Programmierung noch mal vergegenwärtigt.
|
Perl Module selbst schreiben
/
Subroutinen und Variablen von einem Modul in das Hauptprogramm
exportieren |
|
Bei der Erläuterung, wie Perl Module eingebunden
werden, wurde schon einiges erwähnt, was auch von entscheidender
Bedeutung ist, wenn man Perl Module schreiben will:
-
Perl Module müssen auf pm enden.
-
Sie müssen sich in einem Pfad befinden,
in dem Perl tatsächlich nach Modulen sucht.
-
Sie müssen als letzten Wert immer
eine 1 haben, damit ein "wahrer" Wert zurückgegeben
wird.
-
Die Datei muss so heißen, wie das
Package.
-
Perl wird entweder mit use, das ist der
Normalfall oder mit require aufgerufen.Sowohl bei use
aus auch bei require muss die Endung pm beim Aufruf nicht
mit angegeben werden, denn Perl fügt die Endung automatisch
hinzu.
Der Unterschied zwischen use und require
besteht in der Art, wie Module eingebunden werden.
Module, die mit require aufgerufen werden, werden erst dann
eingebunden, wenn sie aufgerufen werden.
Module, die mit use eingebunden werden, werden vor dem eigentlichen
Hauptprogramm aufgerufen.
Machen wir uns das anhand eines Beispiels klar:
der Aufruf eines Moduls
mit use
# Das ist das Modul weihnachten.pm abzuspeichern z.B. in c:/perl/lib mit dem Namen weihnachten.pm
package weihnachten;
print " Nikolaus";
1;
das eigentliche Programm
# Das ist das eigentliche Programm. Es kann überall abgespeichert werden und beliebig heißen.
print "Knecht Rupprecht";
use weihnachten;
Wir sehen, obwohl eigentlich Knecht Rupprecht
zuerst kommen sollte, kommt zuerst Nikolaus. Was lernen wir?
Module, die mit use eingebunden werden, werden vor dem eigentlichen
Hauptprogramm ausgeführt.
der Aufruf eines Moduls mit mit require
# Das ist das eigentliche Programm
print "Knecht Rupprecht";
require weihnachten;
Jetzt kommt raus Knecht Rupprecht Nikolaus.
Prinzipiell gibt es einen Unterschied zwischen Modulen, die
objektorientiert programmiert sind und denen, die nicht objektorientiert
programmiert sind. Bei objektorientierten Modulen kann es
keinen Konflikt zwischen Subroutinen des aufrufenden Programms
und Subroutinen des Moduls geben, da alles in Objekten gekapselt
ist. Beispiel:
# das ist das Modul problem.pm abzuspeichern in z.B. c:/perl/lib mit dem Namen problem.pm
package problem;
sub rechnen
{
$summe=$_[0] + $_[1];
}
1;
# dazu gehört dann dieses Hauptprogramm
use problem;
print &rechnen(50,30);
sub rechnen
{
$summe=$_[0]-$_[1];
}
Wir haben die Funktion rechnen zweimal. Was
die Frage aufwirft, welche von den beiden Funktionen nun eigentlich
ausgeführt wird. Als Ergebnis kommt 20 raus, ein starkes
Indiz dafür, dass die Subroutine rechnen im Hauptprogramm
ausgelöst wurde. Dies Problem entsteht von vorneherein
bei der objektorientierten
Programmierung nicht.
| Das ganze
Modul objektorientiert programmieren |
|
package problem;
sub new
{
$zeiger={};
bless($zeiger);
}
sub rechnen
{
$mein_objekt=shift;
$$mein_objekt{zahla}=shift;
$$mein_objekt{zahlb}=shift;
$summe=$$mein_objekt{zahla}+$$mein_objekt{zahlb};
}
1;
#dann das Hauptprogramm use problem;
$objekt=problem->new; print $objekt->rechnen(40,90);
Bei dieser Variante ist es völlig unerheblich,
ob im Hauptprogramm noch eine Subroutine rechnen auftaucht
oder nicht, da das Objekt zum Package problem gehört.
Folglich wird auch die Subroutine rechnen ausgeführt,
die zu dem Package problem gehört.
Ist das Modul nicht objektorientiert programmiert, so
ist es möglich, dass die selbe Subroutine bzw. Variable
in mehreren packages auftaucht. Damit sie nicht kollidieren
ist das Problem in Perl so gelöst, dass Subroutinen oder
Variablen des einen packages im anderen nicht sichtbar sind.
| den
ganzen Pfad zu der entsprechenden Variablen oder Subroutine
angeben |
|
# das ist das package banane.pm muss in einen Ordner,
in dem perl nach Modulen sucht. Name der Datei banane.pm
package banane;
sub tach
{
print "Guten Tag ".$_[0].$_[1];
}
# das ist das Hauptprogramm, dass das Modul banane.pm aufruft
use banane;
tach ("Herr","Ehmann");
Das funktioniert nicht, da die Subroutine tach
im Hauptprogramm nicht sichtbar ist. Genau genommen ist es
so, dass jedes package ein eigener Namensraum ist. Wir haben
also zwei Namensräume, nämlich banane und main.
main ist der default Namensraum. Eine Variable oder Subroutine
des einen Namensraumes ist im anderen nicht sichtbar, folglich
ist tach im Hauptprogramm nicht sichtbar. Es gibt nun mehrere
Möglichkeiten, tach im Hauptprogramm sichtbar zu machen:
# das ist das package banane.pm muss in einen Ordner,
in dem perl nach Modulen sucht. Name der Datei banane.pm
package banane;
sub tach
{
print "Guten Tag ".$_[0].$_[1];
}
1;
# das ist das Hauptprogramm, welches das Modul banane.pm aufruft
use banane;
&banane::tach ("Herr","Ehmann");
Das Beispiel funktioniert! Man beachte die 1
am Schluss des Moduls banane.pm. Geändert wurde nur die
Zeile:
&banane::tach ("Herr","Ehmann");
Mit dieser Zeile geben wir den vollen Pfad zu der Subroutine
tach an. Diese Syntax erlaubt es auch, eine eventuell vorhanden
Subroutine tach im Hauptprogramm von der Subroutine tach im
package banane zu unterscheiden. Bei dieser Art von Aufruf
muss mit angegeben werden, was aufgerufen wird, also &
für Subroutine und $ für eine Skalarvariable.
Ein weiteres Beispiel:
# das ist das package banane.pm muss in einen Ordner,
in dem perl nach Modulen sucht. Name der Datei banane.pm
package banane;
sub tach
{
print "Guten Tag ".$_[0].$_[1];
}
$hi="Ich wollte mich nur mal nach Ihrem Befinden erkundigen \n";
@hello=(" Perl "," PHP "," XML/XSL "," mysql "," javaScript ");
1;
# das ist das Hauptprogramm, welches das Modul banane.pm aufruft
use banane;
&banane::tach ("Herr","Ehmann \n");
print $banane::hi;
print "Was machen die Handbücher für ". $banane::hello[0].$banane::hello[1].
$banane::hello[2].$banane::hello[3].$banane::hello[4];
Diese Vorgehensweise ist aber bei größeren
Projekten umständlich.
| mit
dem Modul EXPORTER bestimmte Subroutinen und Variablen
exportieren |
|
Es gibt es noch eine alternative Möglichkeit
Symboltabellen, also Subroutinen und Variable, zu exportieren.
Diese wurde oben, bei der Diskussion wie man Module nutzt,
schon beschrieben. Es geht nämlich auch mit: use Exporter;
# das ist das package banane.pm muss in einen Ordner,
in dem perl nach Modulen sucht. Name der Datei banane.pm
package banane;
use Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(tach $hi @hello);
sub tach
{
print "Guten Tag ".$_[0].$_[1];
}
$hi="Ich wollte mich nur mal nach Ihrem Befinden erkundigen \n";
@hello=(" Perl "," PHP "," XML/XSL "," mysql "," javaScript ");
1;
# das ist das Hauptprogramm, welches das Modul banane.pm aufruft
use banane;
tach ("Herr","Ehmann \n");
print $hi;
print "Was machen die Handbücher für ". $hello[0].$hello[1].$hello[2].$hello[3].$hello[4];
Das Modul Exporter muss aber erst mal von Perl
gefunden werden. Deshalb tragen wir es in den Array @ISA ein.
In dem Array @ISA stehen alle packages, von denen banane erben
kann. Bei dem Modul Exporter haben wir jetzt zwei Möglichkeiten.
Dies wurde oben schon erläutert, hier noch mal zur Wiederholung!
Wir haben hier die Möglichkeit, bestimmte Subroutinen
und Variablen immer zu exportieren, oder bestimmte Subroutinen
und Variablen nur dann zu exportieren, wenn das aufrufende
Hauptprogramm diese anfordert.
Im Beispiel oben wurde die Subroutine tach und die Skalarvariable
$hi und der Array @hello in den Array @EXPORT eingetragen.
Dies bewirkt, dass diese Variablen immer in das aufrufende
Programm exportiert werden, völlig unabhängig von
der Frage, ob diese Subroutinen und Variablen vom aufrufenden
Programm überhaupt gebraucht werden.
| Die
zu exportierenden Subroutinen und Variablen in den Array
EXPORTER_OK eingetragen |
|
Eine andere Möglichkeit Variablen und
Subroutinen zu exportieren zeigt das folgende Beispiel:
package banane;
use Exporter;
@ISA = qw(Exporter);
@EXPORT_OK = qw(tach $hi @hello);
sub tach
{
print "Guten Tag ".$_[0].$_[1];
}
$hi="Ich wollte mich nur mal nach Ihrem Befinden erkundigen \n";
@hello=(" Perl "," PHP "," XML/XSL "," mysql "," javaScript ");
1;
# das ist das Hauptprogramm, welches das Modul banane.pm aufruft
use banane qw(tach $hi @hello);
tach ("Herr","Ehmann \n");
print $hi;
print "Was machen die Handbücher für ". $hello[0].$hello[1].$hello[2].$hello[3].$hello[4];
Wie bereitst oben beschrieben, ergeben sich
bei dieser Methode hinsichtlich der Syntax Unterschiede. Die
zu exportierenden Variablen oder Subroutinen werden in den
Array EXPORT_OK eingetragen. Das reicht aber noch nicht, um
sie tatsächlich zu exportieren. Tatsächlich exportiert
werden sie nur, wenn das aufrufende Programm sie anschließend
auch tatsächlich anfordert. Das passiert beim Aufruf
des Moduls mit:
use banane qw(tach $hi @hello);
Was lernen wir? Es gibt also insgesamt vier
Möglichkeiten, Subroutinen und Variablen von einem Modul
in das Hauptprogramm zu exportieren:
-
das ganze Modul objektorientiert programmieren.
Dabei werden die Methoden und Variablen des packages nur
über das dazugehörige Objekt angesprochen. Eine
Kollision mit namensgleichen Subroutinen oder Variablen
des Hauptprogramms ist dann von vorneherein ausgeschlossen.
-
den ganzen Pfad zu der entsprechenden Variablen
oder Subroutine angeben, nach dem Schema &Ordner_in_Bibliothek::package::subroutine().
Auch hier ist eine Kollision mit den Subroutinen und Variablen
des Hauptprogramms nicht möglich.
-
mit dem Modul EXPORTER bestimmte Subroutinen
und Variablen exportieren. Das kann schief gehen, wenn
Subroutinen und Variablen, die auch im Hauptprogramm unter
gleichem Namen erscheinen, exportiert werden.
- die zu exportierenden Subroutinen und Variablen werden
in den Array EXPORTER_OK eingetragen. Tatsächlich exportiert
werden sie aber nur, wenn das aufrufende Modul diese dann
auch tatsächlich anfordert. Bei dieser Variante weiß
der Programmierer, was in das Hauptprogramm importiert wird
und kann die Subroutinen und Variablen entsprechend benennen.
package banane;
use Exporter;
@ISA = qw(Exporter);
@EXPORT_OK = qw(tach $hi @hello);
sub tach
{
print "Guten Tag ".$_[0].$_[1];
}
$hi="Ich wollte mich nur mal nach Ihrem Befinden erkundigen \n";
@hello=(" Perl "," PHP "," XML/XSL "," mysql "," javaScript ");
1;
# das ist das Hauptprogramm, welches das Modul banane.pm aufruft
use banane qw(tach $hi @hello);
tach ("Herr","Ehmann \n");
print $hi;
print "Was machen die Handbücher für ". $hello[0].$hello[1].$hello[2].$hello[3].$hello[4];
sub tach
{
print "Na du Pfeife, biste immer noch nicht fertig ?";
}
Wenn das aufrufende Programm selber eine tach
Subroutine hat, kann Perl sich aussuchen, welche der beiden
Subroutinen ausgeführt wird, die vom package banane oder
die vom package main. Perl entscheidet sich dann für
die tach Subroutine aus dem package main und druckt:
Na du Pfeife, biste immer noch nicht fertig?
Das heißt beim Export von Subroutinen und Variablen
mit dem EXPORTER Modul muss der Programmierer dafür sorgen,
dass er keine Namen vergibt, die mit Namen im Modul kollidieren
können. Übergibt das Modul unaufgefordert Subroutinen
und Variablen, hat er keine Chance, da er hier keine Kontrolle
darüber hat, was exportiert wird.
Aus diesem Grund ist es günstiger, in Verbindung mit
dem EXPORTER Modul die vierte Variante zu wählen. Hier
werden die zu exportierenden Subroutinen und Variablen in
den Array EXPORTER_OK eingetragen. Tatsächlich exportiert
werden sie aber nur, wenn das aufrufende Modul diese dann
auch tatsächlich anfordert. Bei dieser Variante weiß
der Programmierer, was in das Hauptprogramm importiert wird
und kann die Subroutinen und Variablen entsprechend benennen.
|
 |
