Warum ist das Standard-Scoping-Verhalten in Perl so, wie es ist?

Dec 10 2020

Ich lerne Perl für die Schule und lerne derzeit etwas über die Verwendung des mySchlüsselworts und über das Scoping in Perl. (Als Referenz habe ich mir angesehen, wie ich das Schlüsselwort "my" in Perl verwenden soll .) Hoffentlich wurde diese Frage noch nicht an anderer Stelle gestellt, aber wenn nicht ... warum ist Perls Standardverhalten so, wie es ist?

Es scheint mir, dass ein Standardbereich im C-Stil am sinnvollsten ist ... Sie deklarieren eine Variable innerhalb eines Blocks, die Variable existiert innerhalb dieses Blocks, und sobald Sie diesen Block verlassen, ist diese Variable nicht mehr zugänglich. Warum müssen Sie in Perl das mySchlüsselwort verwenden , um dieses Verhalten anzugeben ? Es scheint, dass die Beschränkung des Gültigkeitsbereichs einer Variablen auf den Ort, an dem sie verwendet wird, ein gutes Standardverhalten wäre, und die ständige Verwendung myscheint sehr redundant zu sein und zur Unordnung des Codes beizutragen.

Scheint ein bisschen so, als würde man in ein Lebensmittelgeschäft gehen und sofort lautstark Ihre bevorzugte Marke für das und das erklären, bevor Sie mit dem Einkaufen fortfahren, nur für den Fall, dass jemand in Ihrer Nähe neugierig war (was wahrscheinlich nicht der Fall war).

(Mögliches Duplikat, diese Frage wird möglicherweise entfernt ... Warum sollte die Perl-Variable im Dateibereich mit "my" deklariert werden? )

Antworten

9 ikegami Dec 10 2020 at 06:30

Wenn Sie Variablen mit lexikalischem Gültigkeitsbereich möchten, benötigen Sie eine Deklaration. [1]


Es scheint mir, dass ein Standardbereich im C-Stil am sinnvollsten ist ... Sie deklarieren eine Variable innerhalb eines Blocks, die Variable existiert innerhalb dieses Blocks, und sobald Sie diesen Block verlassen, ist diese Variable nicht mehr zugänglich

Das ist genau , wie es funktioniert in Perl. Wo man eine Variable mit int iin C deklarieren würde, benutzt man my $iin Perl. Beide erstellen eine Variable mit lexikalischem Gültigkeitsbereich, dh eine Variable, die nur im aktuellen Block sichtbar ist und Blöcke enthält. Wenn Code außerhalb des Blocks ausgeführt wird, kann auf die Variable nicht zugegriffen werden. Der Umfang der Variablen in Perl entspricht dem Umfang der Variablen in C. [2]

// Can't use `i` here.           # Can't use `$i` here.
{                                {
   // Can't use `i` here.           # Can't use `$i` here. int i = 4; my $i = 4;
   printf("%d\n", i);       4       say $i; { { printf("%d\n", i); 4 say $i;
      int i = 5;                       my $i = 5; printf("%d\n", i); 5 say $i;
   }                                }
   printf("%d\n", i);       4       say $i; } } // Can't use `i` here. # Can't use `$i` here.

  1. Python hat keine expliziten Variablendeklarationen, aber auch keine Variablen mit lexikalischem Gültigkeitsbereich. Python-Variablen sind funktionsbezogen.

  2. Die Lebensdauer von Variablen ist jedoch nicht gleich. Ein Skalar kann nach dem Ende des Blocks, in dem er sich in Perl befindet, am Leben erhalten werden. Dies ist jedoch bei ähnlichen Variablen in C (Variablen mit "automatischer Speicherdauer") nicht der Fall.

    Zum Beispiel,

    # You can't use `@a` outside of the sub,
    # But you can use the created array anonymously.
    sub f { my @a = qw( abc def ); return \@a; }
    

    In diesem Sinne my $xähnelt es eher einer dynamisch zugewiesenen Struktur.

6 Schwern Dec 10 2020 at 07:00

Denn so hat es Larry Wall 1987 gemacht und Perl 5 bleibt mit dieser Entscheidung abwärtskompatibel. Lexikalische Variablen wurden erst 1994 in Perl 5 eingeführt, und bis dahin gab es eine ziemlich große Installationsbasis für Perl 4-Programme.

Ich werde spekulieren warum. Perl war nicht als Anwendungssprache konzipiert, sondern wurde eine. Perl 1 wurde 1987 als leistungsstärkere Alternative zu sed , awk und Bourne Shell geschrieben .

Wenn Sie ein Problem haben, das normalerweise sed oder awk oder sh verwendet, aber deren Fähigkeiten übersteigt oder etwas schneller ausgeführt werden muss, und Sie das dumme Ding nicht in C schreiben möchten, ist Perl möglicherweise das Richtige für Sie.

Aus dem Perl 1.0-Handbuch .

sed- und awk-Programme sind normalerweise nur eine Zeile. Und in der Shell sind Variablen global. Angesichts des Zwecks von Perl 1 war das in Ordnung.

Akzeptierte Standards für das Software-Engineering haben sich in den letzten Jahrzehnten stark verändert. Damals, als Systeme kleiner und einfacher waren, waren globale Variablen akzeptabler. Mit zunehmender Komplexität sind globale Variablen zunehmend eine Gefahr.

1 lordadmira Dec 12 2020 at 11:15

Genau genommen ist der Standardbereich von Variablen in Perl das globale Paket. Variablen , die nicht deklariert werden müssen . Das sagt viel über Perls Philosophie aus. Es ist aufgabenorientiert und zeichnet sich durch Rapid Prototyping und schnelle und schmutzige Programmierung aus. Sie können komplette Programme in die Befehlszeile schreiben, um ziemlich komplexe Aufgaben zu erledigen ( perl -e). Nur ein Masochist würde es tun perl -e 'use strict; ...'. Sie schreiben einfach Variablen und sie funktionieren einfach. Eine dieser Philosophien ist DWIM - mach was ich meine. Das ist das genaue Gegenteil der meisten "harten" Programmiersprachen, in denen Sie die Welt definieren müssen, bevor Sie etwas tun können.

Dann in Larrys gute Zeit wir haben strict, use vars, my, our, und statedie Verwaltung von Variablen zu vervollständigen. Sie arbeiten für uns, nicht umgekehrt. Tatsächlich kann es als unhöfliche Programmierung angesehen werden, bestimmte Daten nicht global zu speichern. Weil ich es nicht unbedingt besser weiß als der nächste und wenn er meinen Code oder mein Modul überprüfen oder modifizieren möchte, ist das in Ordnung und nachbarschaftlich.

Hier sind einige sehr lehrreiche Links zu Vorträgen von Larry Wall, Perls Schöpfer.

Perl, die erste postmoderne Computersprache

Die Kultur von Perl

Im Ernst, wenn es in der Perl-Kultur einen Keim einer wichtigen Idee gibt, dann ist dies: Zu viel Kontrolle ist genauso tödlich wie zu wenig Kontrolle. Wir brauchen Kontrolle und wir brauchen Chaos.

Programmieren ist schwer, lass uns Scripting gehen ...

Die Frustrationen bei der Unix-Shell-Programmierung führten direkt zur Entwicklung von Perl. Ich fand heraus, dass Shell-Scripting von Natur aus durch die Tatsache eingeschränkt war, dass die meisten seiner Verben nicht unter seiner Kontrolle stehen und die Substantive verarmt sind, auf Zeichenfolgen und Dateien beschränkt sind, mit wer-weiß-was-Typologie. Ich möchte nicht mit einer dummen Computersprache sprechen. Ich möchte, dass meine Computersprache die von mir eingegebenen Zeichenfolgen versteht.

Weitere Informationen finden Sie unter perl.com