Werbung einblenden Werbung ausblenden


Home / Tutorials / Perl Handbuch / Arbeiten mit Modulen

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

Installation der Module

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.

Anwendung der Module

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&auml;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&auml;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.

Verzeichnisse, in denen Perl im Default nach Modulen sucht

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

Zusammenfassung

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.

vorhergehendes Kapitel