problem mit lexikalischen variablen (Seite 2) (Allgemeines zu Perl)

[thread]5612[/thread]

problem mit lexikalischen variablen (Seite 2)

Leser: 2

kabel

2003-08-06 15:46

User since
2003-08-04
704 Artikel
BenutzerIn
[default_avatar]

zur code-länge: sorry.

es ist egal, wo ich tags definiere, in beiden fällen ist die subroutine dispatcher relativ zum hash eine closure - das wollte ich ausdrücken.
es könnte natürlich sein, dass perl auf dem wege
check_link -> HTML::Parser -> ... -> dispatcher
die subroutine dispatcher vorher parsen muss, dann müsste er meckern, dass der hash nicht deklariert ist - was der interpreter nicht macht.

naja, ich überleg mir nachher noch ne genauere antwort. wahrscheinlicher ist, dass ich einem denkfehler unterliege.

-- stefan

2003-08-06 15:54

User since
2003-08-04
12209 Artikel
Admin1

[quote=kabel,06. 08 2003,13:46]es könnte natürlich sein, dass perl auf dem wege
check_link -> HTML::Parser -> ... -> dispatcher
die subroutine dispatcher vorher parsen muss, dann müsste er meckern, dass der hash nicht deklariert ist - was der interpreter nicht macht.[/quote]
nein, check_link() wird aufgerufen, dann wird darin HTML::Parser
aufgerufen, der wiederum ruft dispatcher() auf.
dispatcher() benutzt %tags, aber %tags wurde doch noch gar nicht
initialisiert.
erst nach dem ende von check_link() füllst du %tags
mit werten.
ich hab immer noch nicht verstanden, ob du nicht weisst,
warum %tags davor gefüllt sein muss, oder ob du
nicht weisst, warum perl meckert, oder warum perl nicht
meckert.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:

Wie frage ich & perlintro Wiki:

brian's Leitfaden für jedes Perl-Problem

kabel

2003-08-06 18:01

User since
2003-08-04
704 Artikel
BenutzerIn
[default_avatar]

ich bin von einer falschen vorraussetzung ausgegangen. strict arbeitet anscheinend zur compile-zeit, der hash an sich wird erst zur laufzeit gefüllt. dabei prüft strict nur die verwendung der variablen, nix mehr. und die verwendung ist ja korrekt.

ich hatte doch gerade tatsächlich gedacht, dieses my wird zur compile-zeit ausgeführt, da es konstant ist ... tja :) ich hab den bare block einfach ein BEGIN gegönnt, und siehe da, es tut was es soll.

ich werde darüber noch nachdenken. einstweilen danke.

-- stefan

kabel

2003-08-08 00:17

User since
2003-08-04
704 Artikel
BenutzerIn
[default_avatar]

hmm. ich glaub, der PadWalker baut mist...
guck mal auf den code von foo.bar. dort wird das my auch nach dem aufruf der prozedur main gesetzt, und trotzdem wird das lexikalische array @file gefüllt, nicht das package-array @main::file. also muss das my zur compilezeit den eintrag erstellen - das steht im widerspruch zur ausgabe des PadWalkers, denn dann hätte der hash %hiho definiert sein müssen...

-- stefan

SirLant

2003-08-08 00:23

User since
2003-08-04
516 Artikel
BenutzerIn
[default_avatar]

Ich habe in nem alten Programm auch die Funktionen unter den Aufrufen stehen, funktioniert einwandfrei.

--Programming today is a race between Software Enginers striving to build bigger and better idiot-proof Programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!

Dubu

2003-08-08 02:41

User since
2003-08-04
2145 Artikel
ModeratorIn + EditorIn

user image

[quote=SirLant,07.08.2003, 22:23]Ich habe in nem alten Programm auch die Funktionen unter den Aufrufen stehen, funktioniert einwandfrei.[/quote]
Mit Variablen in Closures? Glaub ich nicht.

Code: (dl )

$ perl -Mwarnings -Mstrict -le 'foo(); { my $var=42; sub foo { print $var; } }'
Use of uninitialized value in print at -e line 1.

$ perl -Mwarnings -Mstrict -le 'foo(); BEGIN { my $var=42; sub foo { print $var; } }'
42

PS: Bin ich der einzige, bei dem der Text

Code: (dl )