globale Variablen, lokale Variablen und Symbol-Tabelle (Frage)

[Philipp Hasenfratz]

Halihallo Roland

Mit my deklarierte Variablen lassen sich von anderen Packages (eg. main::) nicht
ansprechen, da sie im Stack (der "lexikalische Scope") des Moduls gespeichert werden.
our ist nach der Dokumentation eine Art "Durchschnitt" zwischen globalen Variablen
(diese werden in der Symbol-Table des main:: Moduls referenziert) und den lokalen
Variablen die eben im aktuellen Scope definiert sind. Durchschnitt deshalb, da sie

• und damit komme ich auf die eigentliche Antwort der Frage - eben trotz lokalem
  Charakter (Modul-Stack) von anderen Modulen ausgelesen werden können.

Naja, das stimmt nicht ganz. Die our-Variable wird im Symbol-Table des packages gespeichert, in dem sie deklariert wird, nicht unbedingt main::.

Richtig, da habe ich mich kreuz falsch ausgedrückt.

Schoen und gut, aber die entscheidende Frage ist doch, welchen Sinn hat das? Mir scheint, das hilft nur in eingen Faellen, mit einem schlechten Design doch noch irgendwie zurecht zu kommen.

Mit deiner Definition scheint mir das auch so. Das einzige Gegenargument ist für mich,
dass man über use vars und our die Variablen als "Modulvariablen" (meinetwegen im
ganzen lexikalischen Scope) definiert und diese nicht über Konstrukte wie $test::test='1'
iniziieren muss.

die Variable $test ist im Modul test über my deklariert. Erwartungsgemäss wird die
Variable über main::print($test::test) nicht ausgegeben,
Jedenfalls nicht das $test, das Du mit my deklarierst.

Ja, der Default SV_undef.

aber etwas erstaunt mich: Die Variable $test::test wird trotz lokaler Definition in der Symbol-Tabelle referenziert.
Referenziert? Meinst Du, dass ihre Existenz in der Schleife angezeigt wird? Das duerfte daran liegen, dass Du sie vorher mit dem print-Kommando auto-vivified hast.

Schande über mich, das isses! - *JIARGL*, danke.

Nun ja, es gibt hier zwei $test's im package test::. Eine Modul-Variable, die nur existiert, weil Du mit print darauf zugegriffen hast (Auto-Vivification), und dann die my-Variable, die aufgrund ihrer Position auch im ganzen package test:: sichtbar ist, aber nicht von aussen (main::). Das einzige, was mich wundert, ist dass im BEGIN auf die my-Variable zugegriffen wird, nicht auf die Modul-Variable. Man sieht das, wenn man den BEGIN-Block zu

Das die lokale Variablen eine hörere "Priorität" haben ist eigentlich logisch. Perl
greift zuerst auf den Stack zu, falls dort keine Variable gefunden wird, ist die
Symbol-Tabelle (also jetzt doch die Referenzierung aller "Modulvariablen") ein
Fall-Back.

Beispiel:

package test;

our $test = 15;

sub test {
   my $test = 27;
   print $test;
}

Was sollte ausgegeben werden? - Natürlich 27, Zugriff auf die lokale Variable test.

BEGIN {$test::test = 'test';}
abaendert. Dann wird im print-Statement 'test' ausgegeben, da die Variable dann schon eher exisitert und nicht mehr auto-vivified wird. Aber muesste das BEGIN nicht eher als das my-Statement ausgefuehrt werden und daher auf die Modul-Variable $test::test zugreifen (und dabei abgebrochen werden, weil es gegen use strict verstoesst)?

Nicht umbedingt. BEGIN wird zwar zuerst _ausgeführt_, nicht aber zuerst geparsed und
optimized. Ich begebe mich jetzt wieder auf argumentatives Dünneis:

use strict;
my $test = 15;
sub t {
   print $test;
}
t();
1;

funktioniert, aber:

use strict;
sub t {
   print $test;
}
my $test = 15;
t();
1;

aha, $test nicht definiert. Warum? - Als der Parser $test in t() sieht, existierte
die Variable noch nicht auf dem Stack und war auch nicht lokal definiert. Was, wenn
nicht nur auf die Existenz (vorherige Definition) der Variablen geprüft wird, sondern
diese auch gleich auf dem Stack angelegt wird? - Das würde das "Phenomen", dass bei
BEGIN {$test=15;} auf die vorherig definierte 'my'-Variable zugegriffen wird erklären,
denn diese wird lekikalisch zuerst definiert (auch wenn im Sinne von "Laufzeit" die
Variable erst nachher iniziiert wird).

Viele Grüsse

Philipp