Hi,

# cat ./test.pl
#!/usr/bin/perl

use strict;
use warnings;

use lib "./";
our $myVarA = 1;
our $myVarB = 2;
use myTest;

print "\$myVarA = $main::myVarA\n";
print "\$myVarB = $main::myVarB\n";
# cat ./myTest.pm
package myTest;

print "\$myVarA = " . $main::myVarA . "\n";
print "\$myVarB = " . $main::myVarB . "\n";

1;
# perl ./test.pl
$myVarA =
$myVarB =
$myVarA = 1
$myVarB = 2
#

Soweit ich "use" verstanden habe, war das zu erwarten, da "use" vor dem
Kompilieren stattfindet. Lösen liese sich das "Problem", indem man
"use" durch "require" ersetzt.
Nun lese ich aber überall, dass man "use" einem "require" wo immer
möglich vorziehen soll. Ist obiges so eine Ausnahme, oder gibt es auch
einen "use"-Weg?

Ziel ist es, in einem package sicher zu stellen, dass bestimmte $main::
Variablen gesetzt wurden.

Danke und Gruß, Helmut

--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn

Du kannst Die Variablenzuweisungen in einem BEGIN-Block machen, das
wird dann auch zur Compile-Zeit ausgeführt. Dann kommt es nur noch auf
die Reihenfolge von BEGIN-Block und use-Anweisung an (der BEGIN-Block
muss *vor* der use-Anweisung kommen)...


#!/usr/bin/perl

use strict;
use warnings;

use lib "./";

BEGIN{
our $myVarA = 1;
our $myVarB = 2;
}

use myTest;

print "\$myVarA = $main::myVarA\n";
print "\$myVarB = $main::myVarB\n";

ReneeB wrote:

> BEGIN{
> our $myVarA = 1;
> our $myVarB = 2;
> }

Ah, bei BEGIN war ich sogar schon, aber vermutlich stimmte die
Reihenfolge nicht.

Merci, Helmut

--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn

Helmut Schneider wrote:
>
> Ziel ist es, in einem package sicher zu stellen, dass bestimmte $main::
> Variablen gesetzt wurden.

Daran, dass es hakelig ist, lässt sich ablesen, dass du ein
untaugliches Konzept verfolgst. Wenn du die Variablenwerte
$myVarA und $myVarB in myTest brauchst, übergib sie
lieber als Parameter.

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

Frank Seitz wrote:

> Helmut Schneider wrote:
> >
> > Ziel ist es, in einem package sicher zu stellen, dass bestimmte
> > $main:: Variablen gesetzt wurden.
>
> Daran, dass es hakelig ist, lässt sich ablesen, dass du ein
> untaugliches Konzept verfolgst. Wenn du die Variablenwerte
> $myVarA und $myVarB in myTest brauchst, übergib sie
> lieber als Parameter.

package myLdap;
sub connectToLdap ($$$$$) {
my $_ldapDomain = shift;
my $_DC = shift;
my $_port = shift;
my $_ldapBindUser = shift;
my $_ldapBindPass = shift;
[...]
}

Jetzt will ich ein zufälliges Passwort erstellen und benötige hierfür:

*alphanumeric = ('a'..'z', 'A'..'Z', 0..9, '!', '?', '$', '/', '.',
'.', '-', '+', '=');
$pwLength = 10;

Ausserdem soll Net::LDAP $retries mal versuchen, sich mit dem Server zu
connecten:

$retries = 5;

Von den obigen 3 Werten sind aus meiner Sicht mindestens eine konstant
(*alphanumeric), die müssen nicht unbedingt jedesmal einer Subroutine
übergeben werden. Das kostet doch auch Ressourcen, oder nicht (Objekt
übergeben, Kopie erstellen, Kopie wieder löschen)?!

--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn

"J. Strübig" wrote:

> Helmut Schneider schrieb:
> > package myLdap;
> > sub connectToLdap ($$$$$) {
> > my $_ldapDomain = shift;
> > my $_DC = shift;
> > my $_port = shift;
> > my $_ldapBindUser = shift;
> > my $_ldapBindPass = shift;
> > [...]
> > }
> >
> > Jetzt will ich ein zufälliges Passwort erstellen und benötige
> > hierfür:
> >
> > *alphanumeric = ('a'..'z', 'A'..'Z', 0..9, '!', '?', '$', '/', '.',
> > '.', '-', '+', '=');
> > $pwLength = 10;
> >
> > Ausserdem soll Net::LDAP $retries mal versuchen, sich mit dem
> > Server zu connecten:
> >
> > $retries = 5;
> >
> > Von den obigen 3 Werten sind aus meiner Sicht mindestens eine
> > konstant (*alphanumeric), die müssen nicht unbedingt jedesmal einer
> > Subroutine übergeben werden. Das kostet doch auch Ressourcen, oder
> > nicht (Objekt übergeben, Kopie erstellen, Kopie wieder löschen)?!
> >
>
> In dem Fall kannst du da auch default Werte in die Funktion (oder
> Modul) einbauen, aber dazu musst du doch keine Variabeln global
> zugänglich machen.

Ich dachte mir, es macht die Sache vielleicht übersichtlicher, wenn ich
das in main definiere.

> Und was die Performance angeht.
>
> Wenn du diese Funktion millionenmal in dem Skript aufrufst,

Unwahrscheinlich.

--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn

On 2009-10-29 11:23, Helmut Schneider <jumper99*gmx.de> wrote:
> # cat ./test.pl
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use lib "./";
> our $myVarA = 1;
> our $myVarB = 2;
> use myTest;
>
> print "\$myVarA = $main::myVarA\n";
> print "\$myVarB = $main::myVarB\n";
> # cat ./myTest.pm
> package myTest;
>
> print "\$myVarA = " . $main::myVarA . "\n";
> print "\$myVarB = " . $main::myVarB . "\n";
>
> 1;
> # perl ./test.pl
> $myVarA =
> $myVarB =
> $myVarA = 1
> $myVarB = 2
> #
>
> Soweit ich "use" verstanden habe, war das zu erwarten, da "use" vor dem
> Kompilieren stattfindet. Lösen liese sich das "Problem", indem man
> "use" durch "require" ersetzt.
> Nun lese ich aber überall, dass man "use" einem "require" wo immer
> möglich vorziehen soll. Ist obiges so eine Ausnahme, oder gibt es auch
> einen "use"-Weg?

Es ist definitiv eine Ausnahme, dass Du in einem Modul, das mit use
eingebunden wird, Code hast, der sofort ausgeführt wird und nicht nur
der Initialisierung dient. Normalerweise werden in Modulen nur
Funktionen bzw. Methoden definiert und eventuell ein paar Variablen
initialisiert. Wenn Du Dein myTest.pm so umschreibst:

package myTest;

sub print_vars {
print "\$myVarA = " . $main::myVarA . "\n";
print "\$myVarB = " . $main::myVarB . "\n";
}

1;

und dann in test.pl

myTest:rint_vars()

aufrufst, wird es wie gewünscht funktionieren, weil der Aufruf zu einem
Zeitpunkt erfolgt, zu dem $main::myVarA und $main::myVarB schon
initialisiert sind.

Wenn $myVarA und $myVarB der Initialisierung von myTest dienen, dann
ist es vermutlich besser und lesbarer, Du übergibst sie gleich beim use:

use myTest (1, 2);
oder
use myTest (myVarA => 1, myVarB => 2);

und verwendest eine import-Routine in myTest.pm und dort package-globale
Variablen zu setzen.

Oder Du verwendest gleich den objektorientierten Ansatz:

use myTest;

$mytest = myTest->new(myVarA => 1, myVarB => 2);

dann kann die Methode new von myTest damit machen, was sie will (z.B. in
$mytest speichern, oder als package-globale Daten speichern oder
irgendwas damit berechnen und dann vergessen).

Ich tendiere meistens zu letzterem Ansatz.

hp

On 2009-10-29 15:14, Helmut Schneider <jumper99*gmx.de> wrote:
> Frank Seitz wrote:
>
>> Helmut Schneider wrote:
>> >
>> > Ziel ist es, in einem package sicher zu stellen, dass bestimmte
>> > $main:: Variablen gesetzt wurden.
>>
>> Daran, dass es hakelig ist, lässt sich ablesen, dass du ein
>> untaugliches Konzept verfolgst. Wenn du die Variablenwerte
>> $myVarA und $myVarB in myTest brauchst, übergib sie
>> lieber als Parameter.
>
> package myLdap;
> sub connectToLdap ($$$$$) {
> my $_ldapDomain = shift;
> my $_DC = shift;
> my $_port = shift;
> my $_ldapBindUser = shift;
> my $_ldapBindPass = shift;
> [...]
> }
>
> Jetzt will ich ein zufälliges Passwort erstellen und benötige hierfür:
>
> *alphanumeric = ('a'..'z', 'A'..'Z', 0..9, '!', '?', '$', '/', '.',
> '.', '-', '+', '=');
> $pwLength = 10;

In der Funktion connectToLdap()? Wieso soll die ein zufälliges Passwort
erstellen?


> Ausserdem soll Net::LDAP $retries mal versuchen, sich mit dem Server zu
> connecten:
>
> $retries = 5;

Die Variable würde ich aber auf keinen Fall $main::retries nennen, da
sie spezifisch für Dein myLdap Modul ist. Wenn schon, dann heißt sie
$myLdap::retries. Dann kannst Du sie in myLdap mit

our $retries = 5;

definieren und initialisieren und wenn nötig im main mit

$myLdap::retries = 10;

überschreiben.


Aber das schreit wirklich nach einem anderen Interface:

package myLdap;

sub connect {
my %opt = *_;
croak "no domain" unless $opt{domain};
$opt{port} //= 389;
$opt{retries} //= 5;
$opt{pwLength} //= 10;
...
}

und dann rufst Du

myLdap::connect(domain => 'example.net', user => 'joe', ...);

auf.

Oder Du machst Dir gleich ein myLdap Objekt. Die Wahrscheinlichkeit,
dass Du mal zwei davon brauchen könntest, ist ja nicht so klein ...

hp

Helmut Schneider wrote:
>
> Von den obigen 3 Werten sind aus meiner Sicht mindestens eine konstant
> (*alphanumeric), die müssen nicht unbedingt jedesmal einer Subroutine
> übergeben werden. Das kostet doch auch Ressourcen, oder nicht (Objekt
> übergeben, Kopie erstellen, Kopie wieder löschen)?!

Wenn dir die Übergabe zweier skalarer Parameter über den Stack
an eine Subroutine Kopfzerbrechen bereitet, weil dies zu viel Aufwand
sein könnte, solltest du lieber in Assembler programmieren.

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

Helmut Schneider wrote:
> Frank Seitz wrote:
>>
>> Daran, dass es hakelig ist, lässt sich ablesen, dass du ein
>> untaugliches Konzept verfolgst. Wenn du die Variablenwerte
>> $myVarA und $myVarB in myTest brauchst, übergib sie
>> lieber als Parameter.
>
> Von den obigen 3 Werten sind aus meiner Sicht mindestens eine konstant
> (*alphanumeric), die müssen nicht unbedingt jedesmal einer Subroutine
> übergeben werden. Das kostet doch auch Ressourcen, oder nicht (Objekt
> übergeben, Kopie erstellen, Kopie wieder löschen)?!

Untaugliche Konzepte sind oft das Resultat fehlgeleiteter Überlegungen.
So auch hier. Das hört sich vielleicht arrogant an, ist auf
den Punkt gebracht aber der eigentliche Kern des Problems.

Grüße
Frank Seitz
--
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