Export, Export und nochmals Export
Renate K.
- perl
Guten Abend!
Ich kämpfe gerade mit der Modulverarbeitung, wobei ich gestehen muss, dass ich noch keine Perl-Expertin bin.
Ich habe drei Varianten des "Export" gefunden und habe jetzt dazu einige Fragen:
1. Sind alle drei Varianten korrekt bzw. noch aktuell?
2. Kann mir jemand die wesentlichen Unterschiede erläutern oder bewirken alle drei das gleiche?
3. Falls gleiche Wirkung, welche Variante ist zu bevorzugen?
In SELFHTML (Erweiterte Verwendung von use (@EXPORT ...):
package Testmodul;
require Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(%FORMULARFELDER);
@EXPORT_OK = qw($Zeitstempel @Logdaten Besteller_ermitteln);
In SELFHTML (use - Modul einbinden):
package Syntax;
use strict;
use vars qw($VERSION @ISA @EXPORT);
require Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(html_syntax);
....
In "Programmierung mit Javascript, PHP und Perl" (http://www.informatik.uni-mainz.de/~barthel/web/Lektionen1/13/):
package Modul;
require Exporter;
our @ISA = ('Exporter');
our @EXPORT = (Liste_der_Standard_Exporte);
our @EXPORT_OK = (Liste_der_Exporte_auf_Anfrage);
Schon jetzt danke für Ihre Hilfe
Renate K.
Hallo Renate!
Keine Ahnung, ob Larry Wall, außer Linguistik studiert zu haben, auch noch Ökonomie, insbesondere Export/Import, zu seinen Studienfächern zählte ;)
Aber es steht schon in SELFHTML:
<cite>
Die Liste @EXPORT kann Namen der Module aufnehmen,
die in den Namensraum eines einbindenden Scripts
standardmäßig exportiert werden, wenn bei der
Einbindung keine spezielle Importliste angegeben ist.
</cite>
Das bedeutet, Du muss bei »use Modul.pm« nicht explizit angeben, welche Variablennamen, Funktionennamen, etc. Du aus dem Modul in Den Namensraum des einbindenden Scripts (main::) importiert werden sollen.
Steht in @EXPORT z.B. $foo, kannst Du im Skript sofort $foo benutzen, z.B.:
print $foo;
<cite>
Die Liste @EXPORT_OK nimmt dagegen die Namen auf,
die ein einbindendes Script maximal in den eigenen
Namensraum übernehmen kann, aber nicht übernehmen muss.
</cite>
Das bedeutet, die Namen in der EXPORT_OK-Liste werden bereitgestellt. Musst Du auf eine Variable daraus zurückgreifen, musst Du sie explizit importieren:
In @EXPORT_OK steht beispielsweise:
@EXPORT_OK = qw($bar $buzz @blubb);
Im Skript schreibst Du, falls Du $bar brauchst:
use Modul qw($bar);
print $bar;
package Modul;
require Exporter;our @ISA = ('Exporter');
our @EXPORT = (Liste_der_Standard_Exporte);
our @EXPORT_OK = (Liste_der_Exporte_auf_Anfrage);
Das ist mir so mit 'our' noch nie begegnet.
Viele Grüße aus Frankfurt/Main,
Patrick
--
![](http://www.atomic-eggs.com/fuernA.jpg)
\_ - jenseits vom delirium - \_
[[link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash](http://www.atomic-eggs.com/)]
Nichts ist unmöglich? [Doch!](http://www.atomic-eggs.com/cwi/cwi_4.shtml)
Heute schon ge[gök](http://goek.atomic-eggs.com/goek_goek.html)t?
你好 Renate,
package Modul;
require Exporter;our @ISA = ('Exporter');
our @EXPORT = (Liste_der_Standard_Exporte);
our @EXPORT_OK = (Liste_der_Exporte_auf_Anfrage);
Diese Variante solltest du verwenden, außer, dass ich den qw-Operator nutzen würde:
~~~perl
package Modul;
require Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw(Liste_der_Standard_Exporte);
our @EXPORT_OK = qw(Liste_der_Exporte_auf_Anfrage);
Alternativ kannst du, um @ISA, @EXPORT und @EXPORT_OK Paket-Global zu machen, auch use vars benutzen, was rückwärts-kompatibel wäre (our ist erst recht spät eingeführt worden):
package Modul;
require Exporter;
use vars qw(@ISA @EXPORT @EXPORT_OK);
@ISA = qw(Exporter);
@EXPORT = qw(Liste_der_Standard_Exporte);
@EXPORT_OK = qw(Liste_der_Exporte_auf_Anfrage);
Beide Varianten sind richtig. SELFHTMLs Version ist nicht so prickelnd, fliegt einem bei use strict um die Ohren, da die Variablen nicht deklariert wurden.
再见,
克里斯蒂安
SELFHTMLs Version ist nicht so prickelnd, fliegt einem bei use strict um die Ohren, da die Variablen nicht deklariert wurden.
Machst Du bitte ein Ticket auf, sonst geht der Hinweis unter.
Siechfred
Ich habe drei Varianten des "Export" gefunden und habe jetzt dazu einige Fragen:
Das ganze sind keine Varianten von Export, sondern es handelt sich nur um drei Arten, wie du mit globalen Variabeln umgehst.
- Sind alle drei Varianten korrekt bzw. noch aktuell?
ja und Nein, die selfhtml Version könnte man als veraltet bezeichnen. Es ist aber nicht unüblich und auch noch häufig zu finden, die Vererbung des Exportmoduls vor use strict zu setzten um damit eine Fehlermeldung zu vermeiden.
- Kann mir jemand die wesentlichen Unterschiede erläutern oder bewirken alle drei das gleiche?
sie bewirken alle das Gleiche.
- Falls gleiche Wirkung, welche Variante ist zu bevorzugen?
Die 3.
Bzw. könntest du auch Variante 4 verwenden:
use base qw(Exporter);
our @EXPORT = qw(f1);
Und noch was, ich habe den starken Verdacht, dass du diese Personen bist:
Beppo
Nobbi
Bautz
Gernot
Es ist kein Problem hier anonym zu fragen, aber wenn man mit jemanden regelmäßig kommuniziert und diese Person permament ihren Namen ändert ist das lästig und unhöflich, ich Bitte dich eine Identität anzunehmen und dabei zu bleiben und nicht dieses alberne Sockenpuppenspiel weiter zu betreiben.
Verhaltensrichtlinien für alle Poster
Jeder Poster im SELFHTML-Forum sollte folgende Regeln beachten:
* Entscheide dich für ein Pseudonym. Sockenpuppen sind im SELFHTML Forum nicht erwünscht.
Struppi.
Moin Moin!
Ein kleiner Haken ist bei @ISA=qw(Exporter) allerdings dabei: Hier findet eine Vererbung statt. Das ist meistens unproblematisch, aber nicht immer (Man darf z.B. keine Routinen definieren, die den selben Namen wie benutzte Routinen des Exporter-Moduls haben). In aller Regel möchte man seinem Modul nur die import-Routine des Exporter-Moduls hinzufügen, und nicht ALLE Routinen des Exporter-Moduls.
Außerdem arbeitet require Exporter;
erst zur Laufzeit. Dazu besteht keine notwendigkeit, das Exporter-Modul kann (und sollte) bereits zur Compile-Zeit mit use Exporter;
geladen werden, genauer mit use Exporter qw(import);
.
So wird wirklich nur die import()-Routine aus dem Exporter-Modul in das eigene Modul geladen, ohne dass es zu Problemen mit Routinen-Namen kommt.
perldoc Exporter schleppt leider auch immer noch die require-Variante mit sich herum. Good Practices sollte man lesen, leider wird auch hier noch fröhlich von Exporter geerbt, ohne auf die Seiteneffekte deutlich hinzuweisen. Exporting without inheriting from Exporter erklärt halbwegs, warum man immer noch Vererben empfiehlt: Vor Exporter 5.57 (Perl 5.8.3 -- Januar 2004) ging es nicht anders.
Alexander