nicht angemeldet
Struppi
Patrick Andrieu
Patrick Andrieu
Patrick Andrieu
Struppi
Patrick Andrieu
Struppi
Hallo,
kann mir jemand erläutern, was sie folgende Fehlermeldung besagt:
"my" variable $umsatz masks earlier declaration in same scope at c:\mycgibin\ermitt.pl line 7.
Ich habe gefunden mask=Schablone?
Gruß
Thomas
kann mir jemand erläutern, was sie folgende Fehlermeldung besagt:
"my" variable $umsatz masks earlier declaration in same scope at c:\mycgibin\ermitt.pl line 7.
Diese Warnung ist keine Fehlermeldung und sagt, dass du zweimal my $umsatz im gleichen Gültigkeitsbereich verwendest.
Struppi.
Hallo Thomas!
Zu dem Grund der Warnung hat Struppi geantwortet. Zu dem Englisch antwortet jetzt ein Franzose.
Ich habe gefunden mask=Schablone?
Als Substantiv ja. Als Verb ist to mask auch maskieren, verbergen, verschleiern, ich würde hier aber einfach frei mit »überschreibt« übersetzen (auch wenn die Variable vielleicht nur deklariert und nicht definiert wurde):
»Die my-Variable $umsatz überschreibt frühere Deklaration im selben Scope im Skript c:\mycgibin\ermitt.pl, Zeile 7.»
Scope zu überstzen überlasse ich wiederum andere... ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo,
danke für Eure Antworten.
Wenn ich es richtig verstehe, hätte ich dann das my weglassen können, ohne dass sich etwas ändert?
Gruß Thomas
Hallo,
Wenn ich es richtig verstehe, hätte ich dann das my weglassen können, ohne dass sich etwas ändert?
Jow, wenn Du diese grässlichen Meldungen nicht mehr haben willst, schalte die Warnungen ab:
mache die shebang
#!/usr/bin/perl -w
zu
#!/usr/bin/perl
und verzichte auf
use strict;
was nach dem my(); verlangt.
Aber so richtig empfehlen mag ich Dir das nicht ;-)
Lass die Warnungen besser an und nutze strict konsequent! Bei einem Dreizeiler mag das zwar überflüssig erscheinen, ist es aber in facto nicht. Insbesondere bei längeren Scripts.
Also, ich hab da so einen wunderschönen Editor von textpad.com (keine Werbung, daher nicht verlinkt), mit dem kann ich Textbausteine verwalten und auch Makros.
Neues PERL-Script (klick und die Outline kommt):
=schnipp=
#!/user/bin/perl -w
#################################################
use strict;
exit;
#################################################
=schnapp=
... und falls Du mit dem vi unterwegs bist: der kann sowas auch.
Viele Grüße,
Hotte
Hi,
Wenn ich es richtig verstehe, hätte ich dann das my weglassen können, ohne dass sich etwas ändert?
Jow, wenn Du diese grässlichen Meldungen nicht mehr haben willst, schalte die Warnungen ab:
»
Heißt Jow "ja" zu meiner obigen Frage?
Warnungen ausschalten will ich natürlich nicht, sondern ich möchte das Programm dann so abändern, dass es keine Warnungen mehr gibt.
Gruß
Thomas
Warnungen ausschalten will ich natürlich nicht, sondern ich möchte das Programm dann so abändern, dass es keine Warnungen mehr gibt.
Dann musst du ein my $umsatz weglassen.
Struppi.
Warnungen ausschalten will ich natürlich nicht, sondern ich möchte das Programm dann so abändern, dass es keine Warnungen mehr gibt.
Dann musst du ein my $umsatz weglassen.
Ok, ich darf das mal ergänzen ;-)
my $umsatz = 'old_value';
my $umsatz = 'new_value';
-w meckert, wie gehabt (early declaration und so...). Was machen?
my $umsatz = 'old_value';
$umsatz = 'new_value';
Viele Grüße,
Hotte
Ich grüsse den Cosmos,
Jow, wenn Du diese grässlichen Meldungen nicht mehr haben willst, schalte die Warnungen ab:
Also du machst deine Autohupe lauter, weil deine Bremsen nicht funktionieren? Zusätzlich klemmst du die Ölkontrolleuchte ab, damit sie aufhört zu leuchten und kaufst dir nen längern Ölstab, damit er wieder bis zum Öl reicht?
Möge das "Self" mit euch sein
Hallo Thomas!
Wenn ich es richtig verstehe, hätte ich dann das my weglassen können, ohne dass sich etwas ändert?
Du sagst nicht, was Du mit $umsatz vorhast. Wenn du sie deklariert hast:
my $umsatz;
oder aber definiert hast:
my $umsatz = 1_000_000_000;
und ein paar Zeilen später erneut versuchst, sie zu deklarieren oder zu definieren:
my $umsatz = "ein fuffy";
kommt die Warnung, die Du zitierst.
Wenn es Dir darum geht, der bereits deklarierten Variable $umsatz einen anderen Wert zuzuweisen, darfst Du my nicht mehr verwenden:
my $umsatz = 1_000_000_000;
.
.
.
.
einige Zeilen Code später:
$umsatz = "sorry, war doch nur ein fuffy, boss";
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Thomas,
Wenn ich es richtig verstehe, hätte ich dann das my weglassen können, ohne dass sich etwas ändert?
Ich kenne ja Dein Script nicht, aber die Warnung deutet darauf hin, dass Du zweimal eine mit dem gleichen Namen deklarieren wolltest (sie sagt aus, dass Du es hast, was darauf hindeutet, dass Du es wolltest ;-)
Wenn Du nun einfach das my weg lässt, gibt es keine Warnung mehr, aber vermutlich ist Dein Programm falsch, weil Du wahrscheinlich zwei Variablen haben wolltest. Du solltest also angucken, was da passiert und dann den Fehler beheben.
Die beste Übersetzung von "mask" wäre in diesem Kontext wohl "verdeckt".
Die alte Variable ist nicht einfach weg, man kann sie nur nicht mehr direkt sehen. Dass es sie noch gibt, kann man z.B. durch Closures oder auch Referenzen erkennen.
Hier ein Beispiel mit Closure:
perl -we 'my $a = 1; my $f = sub {return $a}; my $a = 2; print $a, $f->(), "\n";'
Ausgabe: 2 1
Grüße
Daniel
Hallo Daniel,
Wenn ich es richtig verstehe, hätte ich dann das my weglassen können, ohne dass sich etwas ändert?
Ich kenne ja Dein Script nicht, aber die Warnung deutet darauf hin, dass Du zweimal eine mit dem gleichen Namen deklarieren wolltest (sie sagt aus, dass Du es hast, was darauf hindeutet, dass Du es wolltest ;-)
Ja ich wollte eine zweite Variable mit gleichem Namen:
#!/usr/bin/perl -w
my $umsatz = 10;
....
package rechne;
my $umsatz = 20;
.....
Hallo Thomas!
Ja ich wollte eine zweite Variable mit gleichem Namen:
#!/usr/bin/perl -w
my $umsatz = 10;
....package rechne;
my $umsatz = 20;
.....
Dann solltest Du ganz unten im Forum diesen Thread lesen ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Dann solltest Du ganz unten im Forum diesen Thread lesen ;)
Danke für den Hinweis, aber da verstehe ich so gut wie gar nichts, obwohl ich jetzt seit über einer Stunde darüber bin. Die Diskussion zieht sich ja bereis seit Tagen hin, und ich habe schon Mühe festzustellen, welcher Beitrag zu welchem gehört.
Da diskutieren Cracks und weniger crackies. Da wird etwas geschrieben und von anderen in Frage gestellt bzw. korrigiert. Wie soll ich als Anfänger das ganze ordnen und bewerten?
Gibt es keine kurze, prägnante und doch verständliche Darstellung der Thematik?
Falls nein, wäre es doch eine dankbare Aufgabe an die Spezialisten, die unterschiedlichen Beiträge zu sichten und daraus ein verständliches Papier zu machen. Meinen aufrichtigen Dank hättet Ihr!
Es scheint ja so grundlegend wichtig zu sein, dass man relativ früh damit anfangen sollte, wenn man Perl lernt.
Jetzt muss ich aber in die Heia, mein Daddy wird unruhig!
Bis morgen
Thomas
Gibt es keine kurze, prägnante und doch verständliche Darstellung der Thematik?
Ja. Eine mit my deklarierte Variabel ist eine lexikalische Variabel, sie ist innerhalb eines Scope gültig. Ein Scope ist entweder ein Block {} oder eine Datei.
Das hat aber nichts mit package zu tun. Die besten Erklärungen sind die von Siechfred. Falls du des englischen mächtig bist, kannst du es mal mit deisem Artikel versuchen http://perl.plover.com/FAQs/Namespaces.html, ich finde da wird die ganze Thematik gut erklärt (allerdings spreche ich schon seit ein paar Jahren Perl)
Es scheint ja so grundlegend wichtig zu sein, dass man relativ früh damit anfangen sollte, wenn man Perl lernt.
Jein. eigentlich ist es kein Problem, der Punkt ist halt nur das ein package kein scope ist, d.h. alle mit my deklarieren Variabeln ausserhalb von subs oder Blöcken sind Dateiweit global.
Da man aber sowieso grundsätzlich packages in Module packen sollte spielt das aber in der Praxis nur bedingt ein Rolle. Du solltest dein package rechne auslagern, dabei solltest du diese Empfehlungen einhalten. Also z.b. das der Modulname immer mit einem Großbuchstaben beginnt.
Struppi.
Hallo Struppi!
Hat es einen Grund, dass der IE da einen 406 bekommt?
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo zusammen,
Gibt es keine kurze, prägnante und doch verständliche Darstellung der Thematik?
... wollte schreiben in Deutsch.
Falls du des englischen mächtig bist, kannst du es mal mit deisem Artikel versuchen http://perl.plover.com/FAQs/Namespaces.html, ich finde da wird die ganze Thematik gut erklärt (allerdings spreche ich schon seit ein paar Jahren Perl)
... Basisenglisch ja, aber all diese Spezilbegriffe und wenn ich auf den link klicke, komme ich auf einen französischen Text (les espaces de nom ...) und dort unter "article original" auf das gleiche Dokument!
Gruß
Thomas
Falls du des englischen mächtig bist, kannst du es mal mit deisem Artikel versuchen http://perl.plover.com/FAQs/Namespaces.html, ich finde da wird die ganze Thematik gut erklärt (allerdings spreche ich schon seit ein paar Jahren Perl)
... Basisenglisch ja, aber all diese Spezilbegriffe und wenn ich auf den link klicke, komme ich auf einen französischen Text (les espaces de nom ...) und dort unter "article original" auf das gleiche Dokument!
seltsam ich sehe einen sehr interessanten Artikel, in englisch, der auf die Problematik eingeht.
Aber die Grundzüge hab ich ja schon erklärt und wie gesagt in dem anderen Thread sind die beiden ersten Postings von Siechfred auf jeden Fall lesenswert.
Struppi.
Die besten Erklärungen sind die von Siechfred.
Da warte ich lieber das Ende der zitierten Diskussion ab. Kurt hat ja mehrmals korrigierend eingegriffen.
Falls du des englischen mächtig bist, kannst du es mal mit deisem Artikel versuchen http://perl.plover.com/FAQs/Namespaces.html, ich finde da wird die ganze Thematik gut erklärt (allerdings spreche ich schon seit ein paar Jahren Perl)
Seltsam: Mit Firefox erhalte ich die franz. Version, ebenso mit Netscape, mit Opera die engl. Version!
Die alte Variable ist nicht einfach weg, man kann sie nur nicht mehr direkt sehen. Dass es sie noch gibt, kann man z.B. durch Closures oder auch Referenzen erkennen.
Hier ein Beispiel mit Closure:
perl -we 'my $a = 1; my $f = sub {return $a}; my $a = 2; print $a, $f->(), "\n";'
Das klingt interessant für zukünftige Tests/Fehlersuchen. Allerdings
verstehe ich das Beispiel nicht.
Kannst Du mir eine einfache Beschreibung dieser Technik nennen?
Bedeutet "Closures oder auch Referenzen", dass Closures und Referenzen
Synonyme sind oder sind Referenzen wieder eine andere Methode um obiges zu erkennen?
Gruß
Thomas
Hallo Thomas,
Der entscheidende Punkt ist (wie schon von anderen erklärt), dass my sich auf den Block oder eine Datei bezieht, nicht auf die Package-Angabe.
Das dürfte wohl einfach historische Gründe haben, denn das ist weder intuitiv noch irgendwie anderweitig sinnvoll.
Die Lösung ist einfach, jedes Package in einer eigenen Datei abzulegen. In der Regel organisiert man Perl-Programme so in Module.
Das Package foo::bar sollte also in der datei foo/bar.pm liegen.
Außerdem sollte die letzte Anweisung des Moduls 1; sein. Das liegt daran, da use foo::bar; fehl schlägt, wenn das Modul einen Wert zurück gibt, der einem "false" entspricht. Nur um diesen nächsten Stolperstein schonmal vorweg zu nehmen.
Perl hat in vielen Stellen historischen Ballast, aber in den nächsten 20 Jahren wird ja vielleicht Perl 6 fertig ;-)
Bedeutet "Closures oder auch Referenzen", dass Closures und Referenzen
Synonyme sind oder sind Referenzen wieder eine andere Methode um obiges zu erkennen?
Das sind zwei ganz unterschiedliche Dinge. Referenzen gab es in dem Beispiel gar nicht.
Closures sind Funktionen, die Zugriff auf den Kontext haben, in dem sie deklariert wurden:
sub counter {
my $count = shift;
return sub {
return $count++;
};
}
my $c1 = counter(5);
my $c2 = counter(2);
my $c3 = c2;
print $c1->(), $c2->(), $c1->(), $c3->();
Ergebnis: 5263
sub {return $count++}; ist eine anonyme Funktion (sie hat keinen Namen) und eine Closure (sie hat Zugriff auf $count, auch nachdem die Funktion counter schon abgelaufen ist. Wohlgemerkt jeweils auf eine andere "Instanz" von $count.)
$c1, $c2 und $c3 sind Referenzen auf die anonyme Funktion. Man sieht, dass sie die Funktion nicht enthalten, sonst würde bei $c2 = c3 die Funktion kopiert. $c3->() ruft aber offensichtlich die selbe Funktion auf. Kopiert wurde an der Stelle also nur ein Verweis auf die gleiche Funktion.
Referenzen sieht man aber noch deutlicher bei Referenzen auf andere Variablen. Das war auch, was ich im vorherigen Posting meinte:
my $a = 1;
my $b = \$a; # referenz auf $a
$$b = 2;
print $a;
Ergebnis: 2
Es gibt außer Referenzen auf Variablen und Funktionen noch solche auf Arrays und Hashes. (my $a = [1, 2, 3]; my $b = {a => 1, b => 2})
Gerade das Konzept der Referenzen ist recht elementar. (Für Perl wie Programmierung überhaupt) Es empfiehlt sich, sich das genauer anzusehen (Buch oder so, die Perl-Dokumentation ist zwar ausführlich aber es fehlt der für Einsteiger notwendige rote Faden)
Grüße
Daniel
Hallo,
nach dem Studium der empfohlenen Literatur habe ich jetzt ein neues Problem.
In dem nachfolgenden Programm habe ich ursprünglich die Funktion p1 aufgerufen und danach deklariert. Da kam die Meldung
'main::sub1() called too early to check prototype ...'
Daraufhin habe ich es mit der Funktion sub2 gerade umgekehrt gemacht, nämlich Deklaration und danach den Aufruf.
Da kam aber wieder eine Meldung (siehe unten)
Ich kenne es von anderen Sprachen, dass man die Funktionsdefinition zu Programmbeginn oder irgendwann später machen kann.
Wie ist es bei Perl?
#!/usr/bin/perl -w
sub sub2 ()
{
print "21: \$v1=$v1\n";
}
my $v1 = 10;
print "00: \$v1=$v1\n";
sub1 ();
sub2 ();
sub sub1 ()
{
print "11: \$v1=$v1\n";
}
Ergebnis:
main::sub1() called too early to check prototype at F:\cgi-bin\p1.pl line 8.
Name "main::v1" used only once: possible typo at F:\cgi-bin\p1.pl line 4.
00: $v1=10
11: $v1=10
Use of uninitialized value in concatenation (.) or string at F:\cgi-bin\p1.pl line 4.
21: $v1=
Gruß
Thomas
Wie ist es bei Perl?
Genauso, nur du verwendest Protoypen, meines Wissen sind die noch nicht ganz ausgereift und man sollte noch die Finger davon lassen.
sub sub2 ()
Ohne Klammer kannst du die Funktion deklarieren wo du willst.
Struppi.
Hallo Struppi,
Ohne Klammer kannst du die Funktion deklarieren wo du willst.
leider nicht!
#!/usr/bin/perl -w
sub sub1
{
print "11: \$v1=$v1\n";
}
my $v1 = 10;
print "00: \$v1=$v1\n";
sub1 ();
Ergebnis
Name "main::v1" used only once: possible typo at F:\cgi-bin\p1.pl line 4.
00: $v1=10
Use of uninitialized value in concatenation (.) or string at F:\cgi-bin\p1.pl line 4.
11: $v1=
Zum Zeitpunkt des Aufrufs der Funktion sub1 ist $v1 definiert und sie hat den Wert 10. Trotzdem ist die Variable in der Funktion nicht bekannt.
Laut Perl-Beschreibung ist die Variable bekannt ab dem Zeitpunkt der Deklaration, dies in Perl aber allerdings im statischen Sinne.
Dies ist ungwöhnlich, oder?
Man müsste daher wohl sagen:
Die Funktion kannst Du deklarieren wo Du willst, allerdings müssen
darin verwendete lexikalische Variablen im Quelltext (statisch) davor deklariert werden. Die Wertzuweisung muss (dynamisch) vor dem Funktionsaufruf erfolgt sein.
Gruß
Thomas
Ohne Klammer kannst du die Funktion deklarieren wo du willst.
leider nicht!
die Funktion schon.
[code lang=Perl]
#!/usr/bin/perl -w
sub sub1
{
print "11: $v1=$v1\n";
hier gibt es noch keine Variabel $v1
}
my $v1 = 10;
Das muss vor der ersten Verwendung stehen, du solltest auf jeden Fall auch use strict verwenden!
Die Funktion kannst Du deklarieren wo Du willst, allerdings müssen
darin verwendete lexikalische Variablen im Quelltext (statisch) davor deklariert werden. Die Wertzuweisung muss (dynamisch) vor dem Funktionsaufruf erfolgt sein.
Wenn du globale (bzw. in dem Falle globale lexikalische) Variabeln verwenden möchtest, ja.
Wovon aber auch abzuraten ist.
Struppi.
Ohne Klammer kannst du die Funktion deklarieren wo du willst.
leider nicht!
die Funktion schon.
Warum? Offensichtlich doch nicht ganz am Anfang des scripts noch vor der Variablendeklaration, wie Du nachstehend schreibst.
Das muss vor der ersten Verwendung stehen, du solltest auf jeden Fall auch use strict verwenden!
strict habe ich absichtlich weggelassen, um diesen Effekt zu sehen.
Wenn du globale (bzw. in dem Falle globale lexikalische) Variabeln verwenden möchtest, ja.
Jetzt bringst Du mich ins Schleudern! Von globalen lexikalischen Variablen habe ich in den Unterlagen nichts gefunden.
Gruß
Thomas
die Funktion schon.
Warum? Offensichtlich doch nicht ganz am Anfang des scripts noch vor der Variablendeklaration, wie Du nachstehend schreibst.
Ja, wenn du globale Variabeln in der Funktion nutzt, dann müssen diese nach der Deklaration mit my stehen.
Das muss vor der ersten Verwendung stehen, du solltest auf jeden Fall auch use strict verwenden!
strict habe ich absichtlich weggelassen, um diesen Effekt zu sehen.
Dann hast du diesen Effekt ja gar nicht.
Wenn du globale (bzw. in dem Falle globale lexikalische) Variabeln verwenden möchtest, ja.
Jetzt bringst Du mich ins Schleudern! Von globalen lexikalischen Variablen habe ich in den Unterlagen nichts gefunden.
Es geht nur um den Begriff global, in dem Fall Dateiweit-global
Struppi.
Wenn du globale (bzw. in dem Falle globale lexikalische) Variabeln verwenden möchtest, ja.
Jetzt bringst Du mich ins Schleudern! Von globalen lexikalischen Variablen habe ich in den Unterlagen nichts gefunden.Es geht nur um den Begriff global, in dem Fall Dateiweit-global
Warum immer neue Begriffe in die Runde werfen? Es gibt lt. Perl keine globale lexikalische Variablen.
Es geht nur um den Begriff global, in dem Fall Dateiweit-global
Warum immer neue Begriffe in die Runde werfen?
weil es das Problem das du hast erklärt.
Struppi.
Hallo Thomas,
Die Begriffe "global", "lexikalisch", "lokal" wurden ja nicht für Perl erfunden. Daher kann man diese Begriffe zur Beschreibung auch in anderer Kombination und anderem Kontext verwenden, als das die Perl-Dokumentation tut. Ich für meinen Teil kenne die Perl-Nomenklatur gar nicht so genau.
Lexikalisch heißt wohl erstmal, dass sich der Gültigkeitsbereich am (syntaktischen) aufbau des Programms orientiert. Solche lexikalischen Gültigkeitsbereiche sind die Datei oder der Block. (Funktionen sind ein Spezialfall von Block. In Perl kann man mit dieser Block-Regel so witzige Sachen machen wie:
{
my $counter = 1;
sub count {
return $count++;
}
}
count hat damit einen nach außen nicht sichtbaren Zustand.
packages bilden keine solchen lexikalischen Gültigkeitsbereiche. Das ist meines erachtens konzeptionell unschön. packages hätte man vielleicht besser auch als eigene lexikalische Strukturen mit Block eingeführt und nicht als Anweisungen, die den aktuellen Namensraum ändern.
Global und lokal sind nun Begriffe, die man eigentlich immer nur in Bezug auf einen Kontext klar verstehen kann. Von daher kann eine Variable, die bezüglich einer Funktion global ist, bezüglich einer Datei eben auch lokal sein.
Man kann auch von im Programm lokalen Variablen sprechen (hast Du ja irgendwo gefragt), wenn man irgend einen Kontext hat, der größer ist als das Programm. Wenn man irgendwelche Technologien für verteilte Programmierung o.ä. verwendet, kann das durchaus vorkommen.
Zu Deiner Erkenntnis, Perl sei keine besonders klar konzeptionierte Sprache:
Es ist nicht das Ziel von Perl, eine einfache, übersichtliche Sprache zu sein. Das Konzept war immer, viele Möglichkeiten und Stile zuzulassen. Das wird wohl auch in Zukunft so bleiben, wenn man sich Entwürfe für die Weiterentwicklung ansieht, obwohl da die Sprache neu entworfen wird.
Dieser Ansatz führt dazu, dass man mit Perl sehr produktiv arbeiten kann.
Für mich (und sicher für viele andere) ist Perl eine Sprache um kleinere Aufgaben sehr schnell zu erledigen, um Abläufe zu automatisieren und verschiedene Teile schnell zusammenzubasteln, weniger eine Sprache um größere, langfristige Projekte zu entwickeln.
Für Perl muss man zudem einfach einen gewissen Stil entwickeln, um sauber zu programmieren. Wenn man jede historisch entstandene Tücke der Semantik (und das mit Packages zähle ich dazu) verwendet, führt das schnell zur Verwirrung.
Grüße
Daniel
Ohne Klammer kannst du die Funktion deklarieren wo du willst.
leider nicht!
die Funktion schon.
Warum? Offensichtlich doch nicht ganz am Anfang des scripts noch vor der Variablendeklaration, wie Du nachstehend schreibst.
Struppi meinte, dass Du die Funktion auch nach ihrem Aufruf notieren kannst - abgesehen von den Variablendeklarationen, das Thema ist denke ich klar geworden. Im Übrigen sind Konstrukte der Art
my $var = 'foo';
foo();
sub foo {
print uc $var;
}
schlechter Stil. Besser wäre, auch unter Prototype-Bedingungen:
sub foo($) {
return uc shift;
}
my $var = 'foo';
print foo($var);
Wenn du globale (bzw. in dem Falle globale lexikalische) Variabeln verwenden möchtest, ja.
Jetzt bringst Du mich ins Schleudern! Von globalen lexikalischen Variablen habe ich in den Unterlagen nichts gefunden.
In Deinem Beispiel ist $v1 scriptglobal, darauf wollte Struppi hinaus. Du solltest lexikalische Variablen in dem Kontext deklarieren, in dem Du sie benötigst (siehe mein kleines Beispiel oben), alles andere ist eine potentielle Fehlerquelle.
Siechfred
Struppi meinte, dass Du die Funktion auch nach ihrem Aufruf notieren kannst - abgesehen von den Variablendeklarationen, das Thema ist denke ich klar geworden. Im Übrigen sind Konstrukte der Art
... dann soll er es doch bitte auch so schreiben.
»
In Deinem Beispiel ist $v1 scriptglobal, darauf wollte Struppi hinaus.
Auch Du verwendest einen Begriff, den ich in der von Euch empfohlenen Perl-Doku nie gelesen habe.
Eine my-Variable, ist dann in dem Block, in dem sie definiert wurde, möglicherweise blockglobal?
Und eine package Variable, die im kompletten Programm gültig ist, nicht aber in einem anderen Programm ist dann programmlokal?
Ich habe den thread von Connie verfolgt und da lief es ab einem gewissen Zeitpunkt ähnlich wie jetzt. Wenn etwas unklar formuliert wurde, und der /die Connie(?) darauf hinwies, dann kam die Verteidigung und der Hinweis "er meinte". Mir wären Tatsachen lieber als Meinungen (sorry aber ich bin Mathematiker und mag klare Aussagen/Definitionen. Daher auch meine Bedenken gegen Perl).
Beispiel aus dem thread von Connie:
Meine Aussage<Connie>:
File kann doch auch genau ein package enthalten.
Deine Antwort<Struppi>:
nein, file ist ein file in dem durchaus mehrere packages sein können.
<Connie>Wieso das "nein" in Deiner Aussage? Habe ich gesagt muss?
Schönen Tag noch
Thomas
In Deinem Beispiel ist $v1 scriptglobal, darauf wollte Struppi hinaus.
Auch Du verwendest einen Begriff, den ich in der von Euch empfohlenen Perl-Doku nie gelesen habe.
Manchmal braucht man halt Begriffe, die nur verdeutlichen, was gemeint ist. "Scriptglobal" ist kein offizieller Begriff aus der Perlwelt und soll nur die _Ähnlichkeit_ zum "Global Scope" untersteichen: Sichtbar überall im Script ab Deklaration. Um bei den Begrifflichkeiten zu bleiben: Dein $v1 ist eine private Variable, die ausschließlich im umgebenden Script sichtbar ist.
Eine my-Variable, ist dann in dem Block, in dem sie definiert wurde, möglicherweise blockglobal?
Könnte man _untechnisch_ aus Sicht der Unterblöcke so sagen ;)
Um bei den Begrifflichkeiten zu bleiben: Sie ist eine private Variable, die nur innerhalb des umschließenden Blocks sichtbar ist.
Und eine package Variable, die im kompletten Programm gültig ist, nicht aber in einem anderen Programm ist dann programmlokal?
Packagevariablen sind immer global.
Mir wären Tatsachen lieber als Meinungen (sorry aber ich bin Mathematiker und mag klare Aussagen/Definitionen. Daher auch meine Bedenken gegen Perl).
Ich habe eine Zusammenfassung geschrieben, evtl. zerstreuen sich damit Deine Bedenken.
Siechfred
Struppi meinte, dass Du die Funktion auch nach ihrem Aufruf notieren kannst - abgesehen von den Variablendeklarationen, das Thema ist denke ich klar geworden. Im Übrigen sind Konstrukte der Art
... dann soll er es doch bitte auch so schreiben.
Oh Mann, du fragst nach der Funktionsdeklaration mischt diese aber mit globalen Variabeln. Genau das habe ich auch geschrieben, wenn du dir jedesmal nur einen Satz rauspickst, den zusammenhang auseinanderreißt, dann macht das ja alles keinen Sinn.
In Deinem Beispiel ist $v1 scriptglobal, darauf wollte Struppi hinaus.
Auch Du verwendest einen Begriff, den ich in der von Euch empfohlenen Perl-Doku nie gelesen habe.
Das hat auch nichts mit Perl zu tun. Eine globale Variabel ist eine die mehrere Gültigkeitsbereiche überschreitet, da es in Perl mehrere Arten Gültigkeitsbereiche gibt musst du einfach das eine mit dem anderen kombinieren.
Eine my-Variable, ist dann in dem Block, in dem sie definiert wurde, möglicherweise blockglobal?
Nein ein Block wäre nur ein Bereich der mit {} eingeklammert ist, ein Gültigkeitsbereich ist aber auch eine Datei.
Und eine package Variable, die im kompletten Programm gültig ist, nicht aber in einem anderen Programm ist dann programmlokal?
Nein, eine package Variabel ist immer global ansprechbar, du musst sie nur Qualifiziert mit dem package Namen ansprechen. Mittlerweile sollten die verschiedenen Gültigkeitsbereiche klar sein.
Ich habe den thread von Connie verfolgt und da lief es ab einem gewissen Zeitpunkt ähnlich wie jetzt. Wenn etwas unklar formuliert wurde, und der /die Connie(?) darauf hinwies, dann kam die Verteidigung und der Hinweis "er meinte". Mir wären Tatsachen lieber als Meinungen (sorry aber ich bin Mathematiker und mag klare Aussagen/Definitionen. Daher auch meine Bedenken gegen Perl).
Ich versteh nicht wo du unklare Aussagen findest, der Thread und die Hinweise an Connie sind klar und deutlich, es gab am Anfang ein paar unklarheiten vor allem im zusammenhang mit our, ansonsten sind die Erklärungen deutlich.
Beispiel aus dem thread von Connie:
Meine Aussage<Connie>:
File kann doch auch genau ein package enthalten.
Deine Antwort<Struppi>:
nein, file ist ein file in dem durchaus mehrere packages sein können.
<Connie>Wieso das "nein" in Deiner Aussage? Habe ich gesagt muss?
Wo du jetzt unklarheiten siehst ist mir unklar?
Connie macht hier genau das gleiche wie du, er pickt sich einen Satz heraus und läßt die Erklärungen der Aussage völlig aussen vor. Hier ging es darum, dass eine mit my deklarierte Variabeln in einer Datei über alle packages global ist, aber nur in der Datei zu Verfügung steht. Es ging nicht um package, sondern um my, deshalb mein Nein.
Struppi.
Connie macht hier genau das gleiche wie du, er pickt sich einen Satz heraus und läßt die Erklärungen der Aussage völlig aussen vor. Hier ging es darum, dass eine mit my deklarierte Variabeln in einer Datei über alle packages global ist, aber nur in der Datei zu Verfügung steht. Es ging nicht um package, sondern um my, deshalb mein Nein.
Ja, immer die andern!
Wenn ich den thread von Connie ansehe, so hat nicht nur sie /er Formulierungen kritisiert und korrigiert, sondern Ihr Euch gegenseitig.
Dies spricht nun leider nicht für eine logisch aufgebaute Sprache Perl.
Ich würde es ebenfalls begrüßen, wenn Ihr die Beschreibung von Siechfred diskutieren würdet, um dort die in den verschiedenen threads
aufgeworfenen Fragen, Unklarheiten, Widersprüche aufzulösen.
Es käme dann bestimmt ein Dokument heraus, das vielen weiterhelfen würde. Aber lasst bitte einen Mathematiker ran, sonst geht es wie mit unseren Gesetzen ( :-) ).
Wieder ernsthaft: Euch vielen Dank. Ich habe das Thema jetzt doch weitestgehend begriffen, wohl wissend, dass manche Ungereimtheiten aus der geschichtlichen Entwicklung von Perl resultieren.
Schönen Tag noch
Thomas
Wenn ich den thread von Connie ansehe, so hat nicht nur sie /er Formulierungen kritisiert und korrigiert, sondern Ihr Euch gegenseitig.
Ich hab niemanden kritisiert oder korrigiert.
Dies spricht nun leider nicht für eine logisch aufgebaute Sprache Perl.
Keine Sprache ist logisch aufgebaut, es wird fast überall Balast mitgeschleppt und Theoretiker und Praktiker stehen sich oft unversöhnlich gegenüber, das ist bei Perl nicht anders als bei Java oder C/C++
Und wie du vielleicht gemerkt hast gibt es durchaus auch Unterschiede im Wissenstand zwischen mir, Patrick und Siechfred.
Ich hab mich bisher mit dem theoretischen Unterbau dieser Frage noch nicht auseinandergesetzt, weil sich mir in der Zeit in der ich in Perl programmiere (rund 10 Jahre) diese Frage noch nicht gestellt hatte. Daher wundere ich mich auch über dieses nachbohren und die Schwierigkeiten, relativ klare Zusammenhänge zu verstehen (in den beiden Threads geht es ja eigentlich nur um my und da gibt es keine Unlogik, nur das Connie Schwierigkeiten hat my und package zu trennen).
Ich würde es ebenfalls begrüßen, wenn Ihr die Beschreibung von Siechfred diskutieren würdet, um dort die in den verschiedenen threads
aufgeworfenen Fragen, Unklarheiten, Widersprüche aufzulösen.
Die da wären?
Struppi.
Wenn ich den thread von Connie ansehe, so hat nicht nur sie /er Formulierungen kritisiert und korrigiert, sondern Ihr Euch gegenseitig. Dies spricht nun leider nicht für eine logisch aufgebaute Sprache Perl.
Hä? Was hat das Konzept von Perl mit unterschiedlichen Wissensständen der hier Postenden zu tun? Ich für meinen Teil habe den Unterschied zwischen Packagevariablen und lexikalischen Variablen missverständlich und z.T. falsch dargestellt, dies hat "Kurt" korrigiert. Dafür hat "Kurt" ein Problem mit dem Verständnis von our gehabt, das nun ebenfalls ausgeräumt ist.
Dieses Forum dient nicht nur dazu, Antworten zu geben, sondern auch der persönlichen Wissens- und Horizonterweiterung. Ich für meinen Teil nehme jedenfalls *nach* diesem Thread für mich in Anspruch, das Variablenkonzept von Perl durchgängig verstanden zu haben. Und damit andere was davon haben, wird's eine wie auch immer geartete Zusammenfassung geben.
Es käme dann bestimmt ein Dokument heraus, das vielen weiterhelfen würde. Aber lasst bitte einen Mathematiker ran, sonst geht es wie mit unseren Gesetzen ( :-) ).
Hehe, und Du glaubst ernsthaft, dass ein Mathematiker der bessere Erklärbär ist?
Siechfred
Hehe, und Du glaubst ernsthaft, dass ein Mathematiker der bessere Erklärbär ist?
Aber dies ist ganz sicher!
Du brauchst nur die Entwicklung der Mathematik über Tausend Jahre beobachten.
Gruß
Thomas
Hallo Thomas,
Hehe, und Du glaubst ernsthaft, dass ein Mathematiker der bessere Erklärbär ist?
Aber dies ist ganz sicher!
Du brauchst nur die Entwicklung der Mathematik über Tausend Jahre beobachten.
Sehe den Thread jetzt erst. Ist das Thema für dich jetzt durch oder brauchst du noch eine kurze, streng formale Beschreibung* des Perlschen Variablenmechanismus? (der gar nicht unlogisch ist sondern eher durch Kombinationsreichtum verwirrt)
bye
Kurt
[*] "mathematisch"
Hallo,
Sehe den Thread jetzt erst. Ist das Thema für dich jetzt durch oder brauchst du noch eine kurze, streng formale Beschreibung* des Perlschen Variablenmechanismus? (der gar nicht unlogisch ist sondern eher durch Kombinationsreichtum verwirrt)
bye
Kurt[*] "mathematisch"
Das wäre super, wenn es so etwas gäbe!
Gruß
Thomas
Hi
Das wäre super, wenn es so etwas gäbe!
Gut vor drei Tagen hatte ich noch ein Konzept ich versuchs mal freischnauze. Erstmal für "use strict" und dann die Unterschiede zu "no strict"
======= use strict.
1. Bevor Perl den Code ausführt weist er allen Variablennamen eine Variablenspeicher zu, abhängig von der aktuell gültigen und explizit notwendigen Deklaration.
=== Geltungsbereich
2. Der Geltungsbereich einer Deklaration hängt vom "lexical scope" ab, d.h. er erstreckt sich sozusagen ab der Deklaration bis zur nächsten schließenden Klammer der gleichen Ebene.
3. Der größtmögliche (Default-)Block ist dabei das aktuelle File selbst, d.h. um jedes File stehen gewissermaßen unsichtbare Klammern. Auch gelten der Inhalt von subs und evals als Blöcke,(sind ja auch geklammert).
4. Die Deklaration gilt auch in eingeschachtelten Blöcken, es sei denn im inneren wird der gleiche Variablenname neu deklariert. Dann gilt die übergeordnete Deklaration nur bis zur neuen.
=== Variablentypen
5. Wurde ein Variablenname mit "my" deklariert handelt es sich um eine private Variable des aktuellen Blockes, genannt "lexical variable". Ausserhalb des "Lexical Scopes" kann auf die Variable nicht mehr zugegriffen werden.
6. Wurde sie mit "our" deklariert, handelt es sich um eine öffentliche Variable, genannt Packagevariable. Auf diese kann während des ganzen Programmablaufs zugegriffen werden, auch von externen Files.
=== Packagevariablen Details
7. Packagevariablen werden verschiedenen Namensräumen zugewiesen, der durch Voranstellung von '::' vor dem Variablennamen explizit adressiert werden kann, z.B. $raum::name. Defaultmäßig gilt der Namensraum 'main'.
8. Der im Scope gültige Namensraum kann mit dem Befehl "package Namensraum' eingestellt werden. (Namensräume können also ebenfalls geschachtelt werden)
9. Mit der Vollform $raum::name kann ich immer noch auf andere Namensräume zugreifen, solche komplette Variablenbezeichnungen sind auch vollständige Deklarationen bei Erstbenutzung (kein our notwendig).
10. Mit our $variablenname deklariere ich eine Variable im aktuellen Namensraum, d.h. selbst wenn sich im scope von "our" der Namensraum durch "package" ändert, gehört der Variablenname immer noch zum Namensraum der letzten Deklaration.
=== Fortgeschrittenes
11. Packagevariablen werden in sogenannten Symboltabellen abgelegt die man mit sogenannten Typeglobs manipulieren kann. Jeder Namensraum hat dafür eine Art Hash als Ablageort.
12. Alle Funktionen gelten auch nur jeweiligen Namensraum und müssen falls notwendig mit raum::sub() aufgerufen werden.
13. Mit "local" bekommen Packagevariablen einen sogenannten "dynamischen scope". Das bedeutet nichts anderes als dass der Inhalt einer globalen Variablen bis zum ende des aktuellen scopes weggesichert und dann restauriert wird, d.h. lokal im scope kann ein anderer Wert in die Symboltabelle geschrieben werden. Dieser Scope ist "dynamisch" da während des Programmablaufs den *Inhalt* einer Packagevariablen manipuliert wird, während my und our "statisch" den *Ort* einer Variablen deklarieren. "Local" ist auch keine echte Deklaration, eine "globale" Packagevariable muss im Scope bereits deklariert sein!!! Die nutzvollen Anwendungsfälle von local sind beschränkt, weswegen man es sparsam einsetzen sollte.
siehe auch http://faq.perl.org/perlfaq7.html#What_s_the_differenc
========= no strict
14. Ohne "strict" fordert perl keine explizite Deklaration von Packagevariablen. M.a.W. alle Variablen die nicht explizit vorher mit "my" als privat deklariert wurden, sind ab erstem Auftreten automatisch als Packagevriable deklariert. Dabei gilt für eine Packagevariable immer der aktuelle Namensraum, (es sei denn man hat vorher den Variablennamen mittels our an ein package gebunden, siehe 10)
15. Bis Perl 5.6 gabs beim Übergang zu strict nur eine Möglichkeit Packagevariablen zu erlauben, nämlich mit
"use vars ...".
Dieses sollte man nur noch bei notwendiger Abwärtskompatibilität nutzen, da der Scope hier umständlich vom denjenigen des aktuellen packages abhängt, statt wie bei "our" verwirrungsfrei 100% analog zu "my" geregelt worden zu sein.
=============================
OK ist wieder mehr geworden als geplant aber ist dafür explizit und aufsteigend gewichtet.
Ein Anfänger braucht erstmal nur den Lexical Scope der Klammerungsebenen der Blöcke zu verstehen und my zu benutzen (bis Regel 5)
Und der Profi kann sich darauf verlassen, dass er unter "strict" beim Auftreten einer Variablen ohne expliziten Namensraum sich nur "rückwärts" nach "oben" hangeln muss bis er auf die letzte Deklaration trifft, die entweder "my" oder "our" lautet, um zu wissen ob die Variable einem Scope oder einem Namensraum gehört.
Konnte ich dir weiterhelfen?
Gruß
Kurt
Hi
- Der größtmögliche (Default-)Block ist dabei das aktuelle File selbst, d.h. um jedes File stehen gewissermaßen unsichtbare Klammern. Auch gelten der Inhalt von subs und evals als Blöcke,(sind ja auch geklammert).
Warum dann unterschiedliches Verhalten, wenn sub Namen hat und wenn nicht - beides sind Blöcke?
Siehe Dein Beitrag,
Zitat:
Will man aber unbedingt dynamisch neue subs erzeugen, die an privaten Variablen eines äußeren Scopes gebunden sind (sogenannte Closures), sollte man das _anonym_ tun, statt einen konkreten Namen (hier unterstest() zu geben.
Gruß
Thomas
HI
kommts du mit dem Regelsatz zurecht???
Ich find die Kurzversion besser...
Warum dann unterschiedliches Verhalten, wenn sub Namen hat und wenn nicht - beides sind Blöcke?
Es gibt auch keinen, in dem Beispiel treibt man aber Schindluder mit "Redefinierungen" von Subs.
Nochmal: >>>Was genau intern abläuft kann ich dir nicht sagen, aber innerhalb einer Routine dynamisch eine andere zu definieren ist komplexe "Metaprogrammierung".<<<
Du RE-definierst hier bei jedem Durchlauf der äußeren Routine die innere neu.
Bzw. du versuchst es, aber Perl weigert sich, mit dem Hinweis, dafür doch lieber anonyme Subs zu nutzen! [*]
DER UNTERSCHIED IST:
Dann erzeugst du jedesmal eine NEUE anonyme innere Routine.
Hier geht es also nicht mehr um Scopes oder Blöcke von Variablen, sondern darum unter welchen Bedingungen man einen Funktion *dynamisch* - d.h. während des Runtime - redefinieren darf.
Aber "Closures" sind echt kein Anfängerthema.
Bye
Kurt
[*] welche Sprachen können das auch?!? Über den genauen Grund warum Perl das nicht implementiert kann ich nur spekulieren ...
Hallo,
kommts du mit dem Regelsatz zurecht???
Ich find die Kurzversion besser...
... mir ist die lange lieber.
Aber Perl ist (vorsichtig ausgedrückt) gewöhnungsbedürftig und offensichtlich einigen Schreibern im Forum auch nicht ganz klar.
Um nur ein Zitat zu nennen:
Subroutinen können an beliebigen Stellen im Programm stehen - dabei hat der Schreiber vergessen, dass es dann unterschiedliches Verhalten ergeben kann (Gültigkeit der Variablen).
Danke für Deine Erläuterungen und auch den anderen.
Gruß
Thomas
Hi
Um nur ein Zitat zu nennen:
Subroutinen können an beliebigen Stellen im Programm stehen - dabei hat der Schreiber vergessen, dass es dann unterschiedliches Verhalten ergeben kann (Gültigkeit der Variablen).
Hand auf herz, wann hast du das letzte mal eine Funktion dynamisch redefiniert? Und in welcher Sprache?
Gruß
KUrt
Hand auf herz, wann hast du das letzte mal eine Funktion dynamisch redefiniert? Und in welcher Sprache?
In Javascript ist dies öfters nötig, allerdings ist dort das Verhalten anders
function get(val, el) {
return function() { alert(val + ':' + el) };
}
function get2(val, el) {
function f() { alert(val + ':' + el) };
return f;
}
window.onload = function() {
var all = document.getElementsByTagName('*');
for(var i = 0; i < all.length; i++) {
var el = all[i];
el.onclick = get(i, el);
// el.onclick = get2(i, el);
}
}
Funktionert beides, in Perl nur das Erste, aber beim zweiten kommt dafür eine Warnung
Struppi.
Hi
Hand auf herz, wann hast du das letzte mal eine Funktion dynamisch redefiniert? Und in welcher Sprache?
In Javascript ist dies öfters nötig, allerdings ist dort das Verhalten anders
Mir ist da sklar, aber Thomas sollte das beantworten, du Streber ;)
function get(val, el) {
return function() { alert(val + ':' + el) };
}
function get2(val, el) {
function f() { alert(val + ':' + el) };
return f;
}window.onload = function() {
var all = document.getElementsByTagName('*');
for(var i = 0; i < all.length; i++) {
var el = all[i];
el.onclick = get(i, el);
// el.onclick = get2(i, el);
}}
Yep, das liegt daran das Funktionen in JS selbst Objekte sind , wenn man sie "stringified" bekommt man sogar den Body geliefert.
Bye
Kurt
Hi Struppi,
ich hab mir nochmal Gedanken über die Unterschiede beider Sprachen gemacht und ich denke die unterschiedlichen Geltungsbereiche von Routine lassen sich durch Perl Namenräume erklären.
Perl merkt sich jede neue Routine in der Symboltabelle des aktuellen Packages, JS hingegen behandelt sie wie lexikale Variablen.
Wenn man also in einer Routine eine andere anlegt ist sie in JS nur im Scope der Mutterroutine sichtbar in Perl jedoch global.
Ciao
Kurt
Hand auf herz, wann hast du das letzte mal eine Funktion dynamisch redefiniert? Und in welcher Sprache?
In Javascript ist dies öfters nötig, allerdings ist dort das Verhalten anders
function get(val, el) {
return function() { alert(val + ':' + el) };
}
function get2(val, el) {
function f() { alert(val + ':' + el) };
return f;
}window.onload = function() {
var all = document.getElementsByTagName('*');
for(var i = 0; i < all.length; i++) {
var el = all[i];
el.onclick = get(i, el);
// el.onclick = get2(i, el);
}}
>
> Funktionert beides, in Perl nur das Erste, aber beim zweiten kommt dafür eine Warnung
>
> Struppi.
ich hab mir nochmal Gedanken [..] gemacht
das läßt dich nicht los ;-)
Perl merkt sich jede neue Routine in der Symboltabelle des aktuellen Packages, JS hingegen behandelt sie wie lexikale Variablen.
kann man wohl so sagen.
Struppi.
Hi
Das Verhalten von Subs lsst sich mit einer einfachen Regel beschreiben:
1. Bennante werden statisch definiert, das heit das jeweils letzte vorkommen im Text ist bindend ...(unabhngig von allen Klammern)
2. Anonyme Subs werden (natrlich) dynamisch definiert.
3. Die vorherigen Regeln fr Geltungsbereiche von Variablen sind zum jeweiligen Deklarationszeitpunkt voll gltig.
Ich finde wenn man umbedingt generisch programmieren mchte sind das gute Regeln.
Gru
Kurt
PS: denkt euch bitte die Umlaute Emacs und Firefox haben unter Debian wohl Kommunikationsprobleme.
#[code lang=perl]
use strict;
sub gen {
# benannte subs werden statisch angelegt,die letzte definition bestimmt.
# deswegen dominiert hier das statisch letzte "nein"
my $gen=shift;
if ($gen eq "JA") {
sub sag {
print "ja $gen\n"
}
}else {
sub sag {
print "nein $gen\n"
}
}
}
gen("JA");
sag();
gen("NEIN");
sag();
gen("JA");
sag();
=for OUTPUT:
nein JA
nein JA
nein JA
=cut
sub gen2 {
# Anonyme subs werden dynamisch angelegt, per Typeglob in die
# Symboltablle kann man sag auch dynamisch anpassen
my $gen=shift;
my $sub;
if ($gen eq "JA") {
$sub=sub {
print "ja $gen\n"
}
}else {
$sub=sub {
print "nein $gen\n"
}
};
*sag=$sub;
}
gen2("JA");
sag();
gen2("NEIN");
sag();
gen2("JA");
sag();
=for OUTPUT:
ja JA
nein NEIN
ja JA
=cut
#[/code ]
'main::sub1() called too early to check prototype ...'
Der Prototype-Check geschieht während der Kompilierung. Und die ist nunmal linear, sodass beim Aufruf vor Deklaration eben diese Warnung geworfen wird. Genauso verhält es sich mit den Variablen, die Du deshalb vor ihrer Verwendung deklarieren musst.
Ich kenne es von anderen Sprachen, dass man die Funktionsdefinition zu Programmbeginn oder irgendwann später machen kann. Wie ist es bei Perl?
Egal, so lange Du keine Prototypen verwenden willst und alle für die Subroutine nötigen Variablen deklariert sind.
Mit dem strict-Pragma wäre es übrigens zum Programmabbruch gekommen.
Siechfred
Hi,
Egal, so lange Du keine Prototypen verwenden willst und alle für die Subroutine nötigen Variablen deklariert sind.
Wie im anderen Beitrag geschrieben, müssen die Variablen dummerweise nicht erst unmittelbar vor Aufruf (zur Laufzeit) der Funktion deklariert werden sondern auch im im Quelltext vor der Funktionsdeklaration.
Gruß
Thomas
Egal, so lange Du keine Prototypen verwenden willst und alle für die Subroutine nötigen Variablen deklariert sind.
Wie im anderen Beitrag geschrieben, müssen die Variablen dummerweise nicht erst unmittelbar vor Aufruf (zur Laufzeit) der Funktion deklariert werden sondern auch im im Quelltext vor der Funktionsdeklaration.
Deinen Einwand verstehe ich jetzt nicht, ich schrieb doch von linearer Kompilierung!?
Siechfred