Variablen an Module übergeben
Helmut Schneider
# cat ./test.pl
#!/usr/bin/perl
use strict;
use warnings;
use myTest;
my $myVar1 = "1";
my $myVar2 = "2";
#myTest::printVars();
printVars();
#
# cat ./myTest.pm
#!/usr/bin/perl
use warnings;
use strict;
sub printVars () {
print "$myVar1\n";
print "$myVar2\n";
}
1;
#
Einmal lese ich, "our $myVar1" ginge, einmal, ich m�sse exportieren,
einmal, ich m�sse "package myTest" verwenden, einmal "use vars ..."
t�te.
Ich will nur ein paar "globale" Variablen definieren und die nicht
jeder Subroutine einzeln mitgeben m�ssen.
Wie?
Danke und Gru�, Helmut
Oliver 'ojo' Bedford
> Ich will nur ein paar "globale" Variablen definieren und die nicht jeder
> Subroutine einzeln mitgeben müssen.
>
> Wie?
Vielleicht hilft 'man Exporter' weiter.
Ciao,
Oliver
Helmut Schneider
Nein, leider nicht.
Ferry Bolhar
> Einmal lese ich, "our $myVar1" ginge, einmal, ich m�sse exportieren,
> einmal, ich m�sse "package myTest" verwenden, einmal "use vars ..."
> t�te.
Dein Code befindet sich in zwei Dateien (Scopes), daher wird "my", dessen
Wirkung auf Scopegrenzen beschr�nkt ist, nicht funktionieren. Wenn du in
beiden Dateien eine Variable $myVar1 deklarierst, so werden das zwei
verschiedene Variable mit demselben Namen sein.
Du kannst:
-) entweder in test.pl am Beginn "use vars" verwenden, um die Variablen, die
auch in myTest.pm vorhanden sein sollen, zu deklarieren (und zwar _vor_ dem
"use myTest"). Das ist die �ltere (und mittlerweile nicht mehr �bliche)
Variante;
-) oder am Beginn _beider_ Dateien "our" verwenden - das ist neue, seit Perl
5.6 m�gliche Variante. Hinweis: mit "our" deklarierst du keine Variable,
sondern lediglich die Absicht, sie im aktuellen Scope (hier in den Dateien
test.pl und myTest.pm) zu benutzen.
"package" ben�tigst du hier nicht, da du ja die Variablen aus beiden
Codeteilen heraus ansprechen m�chtest und "package" gerade das bewusst
erschwert.
LG, Ferry
--
Oliver 'ojo' Bedford
Hmm.
package myTest
our $myVar1;
out $myVar2;
in myTest.pm verwenden und dann in test.pl
mit $myTest::myVar1 darauf zugreifen?
Oliver
Helmut Schneider
> Am Tue, 27 Oct 2009 09:32:26 +0000 schrieb Helmut Schneider:
>
> > Oliver 'ojo' Bedford wrote:
> >
> >> Am Mon, 26 Oct 2009 22:52:07 +0000 schrieb Helmut Schneider:
> >>
> >> > Ich will nur ein paar "globale" Variablen definieren und die
> nicht >> > jeder Subroutine einzeln mitgeben müssen.
> >> >
> >> > Wie?
> >>
> >> Vielleicht hilft 'man Exporter' weiter.
> >
> > Nein, leider nicht.
>
> Hmm.
>
> package myTest
> our $myVar1;
> out $myVar2;
>
> in myTest.pm verwenden und dann in test.pl
> mit $myTest::myVar1 darauf zugreifen?
Jaja, die (meisten) Möglichekiten kenne ich ja (wobei ich aus der
myTest.pm heraus auf $test::myVar1 zugreifen möchte, nicht umgekehrt),
nur jeder sagt was anderes. Daher wüsste ich gerne (soweit möglich),
welches die anerkannteste, sauberste, politisch korrekteste Lösung ist
- sofern es die gibt.
Gruß, Helmut
Helmut Schneider
> "Helmut Schneider":
>
> > Einmal lese ich, "our $myVar1" ginge, einmal, ich m�sse exportieren,
> > einmal, ich m�sse "package myTest" verwenden, einmal "use vars ..."
> > t�te.
>
> Dein Code befindet sich in zwei Dateien (Scopes), daher wird "my",
> dessen Wirkung auf Scopegrenzen beschr�nkt ist, nicht funktionieren.
> Wenn du in beiden Dateien eine Variable $myVar1 deklarierst, so
> werden das zwei verschiedene Variable mit demselben Namen sein.
>
> Du kannst:
>
> -) entweder in test.pl am Beginn "use vars" verwenden, um die
> Variablen, die auch in myTest.pm vorhanden sein sollen, zu
> deklarieren (und zwar vor dem "use myTest"). Das ist die �ltere (und
> mittlerweile nicht mehr �bliche) Variante;
>
> -) oder am Beginn beider Dateien "our" verwenden - das ist neue, seit
> Perl 5.6 m�gliche Variante. Hinweis: mit "our" deklarierst du keine
> Variable, sondern lediglich die Absicht, sie im aktuellen Scope (hier
> in den Dateien test.pl und myTest.pm) zu benutzen.
>
> "package" ben�tigst du hier nicht, da du ja die Variablen aus beiden
> Codeteilen heraus ansprechen m�chtest und "package" gerade das
> bewusst erschwert.
Super, auch/gerade der Hinweis mit "our"!
Merci, Helmut
Frank Seitz
>
> Daher wüsste ich gerne (soweit möglich),
> welches die anerkannteste, sauberste, politisch korrekteste Lösung ist
> - sofern es die gibt.
Die absolut richtige Lösung gibt nicht, da TMTOWTDI.
Aus meiner Sicht ist es das sauberste, objektorientiert zu programmieren
und auf globale Variable ganz zu verzichten.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Homepage: http://www.fseitz.de/
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
"J. Strübig"
> Jaja, die (meisten) M�glichekiten kenne ich ja (wobei ich aus der
> myTest.pm heraus auf $test::myVar1 zugreifen m�chte, nicht umgekehrt),
> nur jeder sagt was anderes. Daher w�sste ich gerne (soweit m�glich),
> welches die anerkannteste, sauberste, politisch korrekteste L�sung ist
> - sofern es die gibt.
Neben dem von Frank erw�hnten Vorgehen, ist dies mittels Exporter, aber
das hilft dir ja nicht weiter.
Struppi.
Helmut Schneider
> Helmut Schneider wrote:
> >
> > Daher wüsste ich gerne (soweit möglich),
> > welches die anerkannteste, sauberste, politisch korrekteste Lösung
> > ist - sofern es die gibt.
>
> Die absolut richtige Lösung gibt nicht, da TMTOWTDI.
>
> Aus meiner Sicht ist es das sauberste, objektorientiert zu
> programmieren und auf globale Variable ganz zu verzichten.
Gut, nachdem keiner protestiert (im Gegenteil) werden ich mir OO
angewöhnen. Spricht was dagegen, die Module unter
/usr/local/lib/perl5/site_perl/5.8.9/myModules
abzulegen?
use lib "/usr/local/lib/perl5/site_perl/5.8.9/myModules/";
use mySendMail;
use myDiskIO;
use myLDAP;
Gruß, Helmut
"J. Strübig"
> Gut, nachdem keiner protestiert (im Gegenteil) werden ich mir OO
>
> /usr/local/lib/perl5/site_perl/5.8.9/myModules
>
> abzulegen?
In dem Fall spricht etwas dagegen.
Da geh�ren (wenn) nur Module hinein, die allgemein benutzbar sind, nicht
f�r eine konkrete Anwendung, was deine urspr�ngliche Frage aber impliziert.
Struppi.
Frank Seitz
Der Ort ist schon richtig, nur per Hand dort ein Subverzeichnis
anzulegen, statt ein installierbares Modul zu bauen, ist total daneben.
Gr��e
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen f�r Ihr Internet und Intranet
Helmut Schneider
> J. Str�big wrote:
> > Helmut Schneider schrieb:
> >> Gut, nachdem keiner protestiert (im Gegenteil) werden ich mir OO
> >> angew�hnen. Spricht was dagegen, die Module unter
> > >
> >> /usr/local/lib/perl5/site_perl/5.8.9/myModules
> > >
> >> abzulegen?
> >
> > In dem Fall spricht etwas dagegen.
> > Da geh�ren (wenn) nur Module hinein, die allgemein benutzbar sind,
> > nicht f�r eine konkrete Anwendung, was deine urspr�ngliche Frage
> > aber impliziert.
>
> Der Ort ist schon richtig, nur per Hand dort ein Subverzeichnis
> anzulegen, statt ein installierbares Modul zu bauen, ist total
> daneben.
Ich benutze das f�r den *Hausgebrauch*. Aber bitte, so tief, wie ich
nun eh schon drin stecke, Links f�r Anf�nger zum Thema "installierbare
Module" nehme ich gerne auch noch an.
--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn
Frank Seitz
> Frank Seitz wrote:
>> J. Str�big wrote:
>>> Helmut Schneider schrieb:
>>>> Gut, nachdem keiner protestiert (im Gegenteil) werden ich mir OO
>>>> angew�hnen. Spricht was dagegen, die Module unter
>>>>
>>>> /usr/local/lib/perl5/site_perl/5.8.9/myModules
>>>>
>>>> abzulegen?
>>> In dem Fall spricht etwas dagegen.
>>> Da geh�ren (wenn) nur Module hinein, die allgemein benutzbar sind,
>>> nicht f�r eine konkrete Anwendung, was deine urspr�ngliche Frage
>>> aber impliziert.
>> Der Ort ist schon richtig, nur per Hand dort ein Subverzeichnis
>> anzulegen, statt ein installierbares Modul zu bauen, ist total
>> daneben.
>
> Ich benutze das f�r den *Hausgebrauch*.
Das ist doch kein Grund, es d�mlich machen zu wollen, oder?
> Aber bitte, so tief, wie ich
> nun eh schon drin stecke, Links f�r Anf�nger zum Thema "installierbare
> Module" nehme ich gerne auch noch an.
$ perldoc perlnewmod
Schau in der Gegend, wo das Kommando
module-starter --module=Foo::Bar --author="Your Name" --email=your...@cpan.org
erw�hnt wird.
Helmut Schneider
> Helmut Schneider wrote:
> > Frank Seitz wrote:
> >> J. Str�big wrote:
> >>> Helmut Schneider schrieb:
> >>>> Gut, nachdem keiner protestiert (im Gegenteil) werden ich mir OO
> >>>> angew�hnen. Spricht was dagegen, die Module unter
> > > > >
> >>>> /usr/local/lib/perl5/site_perl/5.8.9/myModules
> > > > >
> >>>> abzulegen?
> >>> In dem Fall spricht etwas dagegen.
> >>> Da geh�ren (wenn) nur Module hinein, die allgemein benutzbar sind,
> >>> nicht f�r eine konkrete Anwendung, was deine urspr�ngliche Frage
> >>> aber impliziert.
> >> Der Ort ist schon richtig, nur per Hand dort ein Subverzeichnis
> >> anzulegen, statt ein installierbares Modul zu bauen, ist total
> >> daneben.
> >
> > Ich benutze das f�r den Hausgebrauch.
>
> Das ist doch kein Grund, es d�mlich machen zu wollen, oder?
Aber ich wollte doch nur eben mal[tm] ein/zwei Shell Scripten, welche
ich regelm�ssig f�r administrative Dinge verwende, nach Perl migrieren
und dabei ein wenig Spass haben - auch viel lernen, ja, aber prim�r
Spass haben...
"J. Strübig"
> J. Str�big wrote:
>> Helmut Schneider schrieb:
>>> Gut, nachdem keiner protestiert (im Gegenteil) werden ich mir OO
>>> angew�hnen. Spricht was dagegen, die Module unter
>>>
>>> /usr/local/lib/perl5/site_perl/5.8.9/myModules
>>>
>>> abzulegen?
>> In dem Fall spricht etwas dagegen.
>> Da geh�ren (wenn) nur Module hinein, die allgemein benutzbar sind, nicht
>> f�r eine konkrete Anwendung, was deine urspr�ngliche Frage aber impliziert.
>
> Der Ort ist schon richtig, nur per Hand dort ein Subverzeichnis
> anzulegen, statt ein installierbares Modul zu bauen, ist total daneben.
Du meinst also ein Konfigurationsmodul - zumindest lese ich das aus den
bisherigen raus - geh�rt in den Ordnern f�r allgemeine Module?
Da bin ich anderer Meinung.
Struppi.
Ferry Bolhar
> Aus meiner Sicht ist es das sauberste, objektorientiert zu programmieren
> und auf globale Variable ganz zu verzichten.
Es gibt sicher F�lle, wo das (OO) richtig ist, aber so allgemein w�rde ich
das nicht formulieren.
OO um jeden Preis macht keinen Sinn und man kann auch prozedural ohne
Verwendung globaler Variable programmieren.
LG, Ferry
--
--
Ing. Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolh...@wien.gv.at
Peter J. Holzer
Er meint wohl eher, dass unter /usr/local/lib/perl5/site_perl/5.8.9/
keine Directories hineingeh�ren, die nicht als Namensraum dienen:
/usr/local/lib/perl5/site_perl/5.8.9/myModules/Bla.pm
sollte mit
use MyModules::Bla;
geladen werden und nicht anders.
Wenn man Module f�r eine spezielle Anwendung hat, dann sehe ich zwei
M�glichkeiten:
1) Man w�hlt einen geeigneteten Namensraum f�r die Applikation (z.B.
App::MyApp) und installiert und verwendet die Module dann ganz
normal. Dann liegt halt z.B. App::MyApp::Config in
/usr/local/lib/perl5/site_perl/5.8.9/App/MyApp/Config.pm
und wird ohne weitere Magie mit
use App::MyApp::Config
geladen.
2) Man installiert die gesamte Applikation in ein bestimmtes Directory,
z.B. /opt/myapp. Dann liegt das Modul Config beispielsweise in
/opt/myapp/lib/perl5/Config.pm
und wird mit
use lib '/opt/myapp/lib/perl5';
use Config;
geladen.
Die beiden Methoden kann man dann nat�rlich auch noch kombinieren.
Bei einem Webprojekt, an dem ich mitarbeite, hei�t beispielsweise das
zentrale Module WZRP::DAL. Damit auf verschiedenen virtuellen Servern
verschiedene Versionen laufen k�nnen (mehrere Developer, Test,
Produktion), wird das nach
/usr/local/www/offline/$virtserver/lib/perl5/ installiert. Meine
Testversion liegt also unter
/usr/local/www/offline/hjp.fiw/lib/perl5/WZRP/DAL.pm, die
Produktionsversion unter
/usr/local/www/offline/dal.fiw/lib/perl5/WZRP/DAL.pm. Im
(FastCGI)-Script steht auf jeden Fall nur
use WZRP::DAL, der Webserver setzt f�r jeden virtuellen Server PERL5LIB
passend.
hp
Martin Vorlaender
> 2) Man installiert die gesamte Applikation in ein bestimmtes Directory,
> z.B. /opt/myapp. Dann liegt das Modul Config beispielsweise in
> /opt/myapp/lib/perl5/Config.pm
> und wird mit
> use lib '/opt/myapp/lib/perl5';
> use Config;
> geladen.
Oder noch geschickter, weil pfad-unabhï¿œngig:
use FindBin;
use lib "$FindBin::Bin/lib/perl5";
use Config;
cu,
Martin
--
One OS to rule them all | Martin Vorlaender | OpenVMS rules!
One OS to find them | work: m...@pdv-systeme.de
One OS to bring them all | http://vms.pdv-systeme.de/users/martinv/
And in the Darkness bind them.| home: martin.v...@t-online.de