http://perl.plover.com/FAQs/Namespaces.html#When_t...

Kann man das wirklich so empfehlen? (s.Betreffzeile)
Ich sehe sooooo häufig die Verwendung von local.

Was meint Ihr?

Sagen wir mal, man sollte local nur dann benutzen, wenn man genau weiß, warum man jetzt gerade my nicht benutzen soll/kann. Der einzige Fall, der mir jetzt spontan für local einfällt ist:

Man sollte sich einfach bewusst sein, dass local nicht für lokale Variablen gedacht ist – dafür gibt es eben my – sondern für das lokale und temporäre Verändern des Wertes einer globalen Variablen.

Neben dem Beispiel von Taulmarill ist meines Erachtens auch noch bei folgendem Konstrukt der Einsatz von local kritisch wichtig:

(Wenn man hier kein local verwendet und sich innerhalb einer Subroutine befindet zerschießt man dem aufrufenden Code den Inhalt von $_, was ungewünschte Konsequenzen haben kann.)

In Perl 5.10 sieht die Situation nochmal etwas anders aus, da hier im Spezialfall $_ nahezu identisches Verhalten aus den Deklarationen local $_ und my $_ resultiert.

local bringt weniger ungewollte weiteneffekte als my und deswegen benutz ich nur local wenn ich unbedingt muss.

vergiss bitte nicht das local der erste versuch war in perl sowas wie lokale variablen zu hacken und es mit einem verhalten simuliert wurde das in meisten fällen geht aber in meisten fällen nicht das ist was du erwartest.

Man muss bei local auch immer aufpassen mit der Sichtbarkeit von Veränderungen:



Ausgabe:

Ich verwende local nur bei dem von Taulmarill genannten Fall. Bei while-Schleifen verzichte ich auf $_ und verwende eine lexikalische Variable.

RalphFFM+2008-02-01 10:30:34--

Kann man das wirklich so empfehlen? (s.Betreffzeile)

ja

Quote

Ich sehe sooooo häufig die Verwendung von local.

dann ist es alter code (my gibt es seit perl 5.4) und/oder schlechter code.
das einzige, wofür du local brauchst, sind vordefinierte variablen wie $/, $_ und die
standard-filehandles. in seltenen fällen auch für eigene variablen.

Man braucht local eigentlich höchstens dann, wenn my eh einen Fehler ausgeben würde. Also hat man so gut wie nie die Wahl.

Naja, ok, 5.10... wie isn das, braucht man local da jetzt ueberhaupt noch, wenn man auch my auf Spezialvariablen anwenden kann?

Taulmarill+2008-02-01 10:42:26--

Sagen wir mal, man sollte local nur dann benutzen, wenn man genau weiß, warum man jetzt gerade my nicht benutzen soll/kann. Der einzige Fall, der mir jetzt spontan für local einfällt ist:

Code (perl): (dl )

1
2
3
4

{
    local $/ = undef;
    $einfach_alles = <FILE>;
}

Oder (falls man aus irgendwelchen Gründen die OO-Notation von Data::Dumper nicht verwenden möchte):

Eigentlich generell überall, wo Modulverhalten über globale Variablen gesetzt wird. Das ist insbesondere bei alten CPAN-Modulen oft der Fall.

betterworld+2008-02-01 17:40:05--

[...]
Naja, ok, 5.10... wie isn das, braucht man local da jetzt ueberhaupt noch, wenn man auch my auf Spezialvariablen anwenden kann?

Man braucht schon deswegen weiterhin local, weil $_ die einzige Spezialvariable ist, die sich bei Perl 5.10 besonders verhält, wenn man eine lexikalische Version von ihr mit my deklariert.

Geändert hat sich hier effektiv auch nicht das Verhalten des Perlkerns sondern des Perlcompilers, welcher an den Stellen, wo er schon immer automatisch einen Zugriff auf $_ in den Parsetree einfügt, nun zuerst den lokalen lexikalischen Namensraum nach einem $_ durchsucht und erst falls es ein solches nicht gibt das globale $_ benutzt.

Im Übrigen hat diese Änderung des Compilers auch den netten Spinoff, dass es jetzt einen Subroutinenprototypen _ gibt, welcher $ entspricht, wobei der Parameter aber implizit mit $_ belegt wird, wenn er nicht explizit angegeben wird.

Das Verhalten von my $_ und local $_ ist aber natürlich auch unter Perl 5.10 noch subtil verschieden – nur für die klassischen Anwendungsfälle macht es keinen Unterschied mehr. Nur mal als Beispiel: