[quote=kabel,07.01.2004, 17:04][quote=Crian,07.01.2004, 15:10]Also ich finde, dass "modulglobale" Variablen nicht so "bah" sind, wie ganz globale.[/quote]
jede variable, die von einer beliebigen stelle im programm
(ohne aufwand) manipuliert werden kann, ist global. die eigenschaft
modulglobal gibt es AFAIK in perl nicht.

@havi: nix für ungut[/quote]
Schon ok!

Ich hatte darueber erst eine heftige Diskussion, darum...

Gruss

[quote=eisbeer,07.Jan..2004, 19:36]Wenn ich - wie zur Zeit - grosse webprogramme schreibe pack ich immer alle
Sessiondaten, Formulardaten und Configdaten in jeweils einen grossen, globalen
Hash...
[/quote]
Der Vorteil an mit my oder use vars deklarierten Variablen ist, dass beim Compilieren sofort ein Fehler ausgespuckt wird, wenn man sich vertippt hat. Bei Hashes hat man diesen Vorteil nicht. Oder benutzt du pseudo-hashes, use fields oder Hash::Util::lock_keys?

Globale Variablen sind eigentlich deswegen von Übel, weil sie den Informationsfluss verschleiern.

Wenn man normaleerweise eine Funktion hat, die drei Parameter bekommt und zwei erzeugt, dann weiß man normalerweise, was reingeht und was raus.

Werden aber plötzlich globale Variablen benutzt, die Parameter oder Rückgabewerte ganz oder teilweise ersetzen, kann man die Funktionsweise der Funktion weniger leicht verstehen und man kann den Code auch schlechter wiederverwenden.

Ich bin ein Freund von klaren Schnittstellen, deshalb vermeide ich globale Variablen weitestgehend.
Ich verwende sie meistens eher als Konstantenersatz o.ä.

Zum Einwurf es gäbe keine Modul-globalen Variablen: Wenn jemand den Qualifier davor schreibt, kommt er natürlich an den Inhalt ran, aber damit ist dann auch schon dokumentiert, woher die Variable stammt. Das macht sie nicht viel besser, aber etwas.

Ich bin da vielleicht etwas von C / C++ verwöhnt, wo man mit Namensräumen und Dateien die Gültigkeit von Variablen stark beeinflussen kann.

@ptk:
Nein, ich teste meine Programme nur laufend und vermeide so Fehler.
Und da ich sowieso max. 4 globale Hashes hab, ist der aufwand nicht sooo
gross.

Was hätte ich für Vorteile von z.B. use fields ? Noch kann ichs ändern,
noch bin ich relativ am Anfang meines neusten Projekts :)

Damit kann man das Hash auf eine bestimmte Anzahl Schlüsselwerte begrenzen.

[quote=eisbeer,08.Jan..2004, 18:22]@ptk:
Nein, ich teste meine Programme nur laufend und vermeide so Fehler.
Und da ich sowieso max. 4 globale Hashes hab, ist der aufwand nicht sooo
gross.

Was hätte ich für Vorteile von z.B. use fields ? Noch kann ichs ändern,
noch bin ich relativ am Anfang meines neusten Projekts :)[/quote]
Gucken wir uns folgendes Skript an:


Hier wird fuer Objekte der Klasse "Bla" festgelegt, dass es nur foo, bar und bla enthalten darf. Eine Zuweisung mit dem Key "foo" funktioniert, mit "vertippt" aber nicht. Das wird zur Laufzeit gemacht, wie die Ausgabe von "Runtime" beweist.

Man kann die Ueberpruefung sogar zur Compilezeit machen, indem man schreibt. Dann wird die Fehlermeldung ausgegeben, bevor das Skript ausgefuehrt wird.

Ein Nebeneffekt bei der Verwendung von "use strict" ist, dass intern Pseudo-Hashes verwendet werden, also Hashes, die intern als Arrays aufgebaut sind. Man erhoffte sich dadurch eine Steigerung der Performance, die aber nicht (oder kaum) aufgetreten ist.

Pseudo-Hashes laufen mit perl5.8.x aus. "use fields" wird weiterhin funktionieren, aber intern wird dann mit Hash::Util::lock_keys gearbeitet. Praktisch heisst das, dass nur die Runtime-Checks erhalten bleiben, aber nicht mehr die Compiletime-Checks.

Alternativen zu "use fields" sind beispielsweise Class::Accessor oder Class::Struct, wobei automatisch Methoden zum Auslesen und Beschreiben von Members erzeugt werden.

Ahja, klingt zwar intressant, ich bleibe jedoch vorerst
bei meiner bewährten Methode.

Danke für das ausführliche Beispiel, ptk !

Du kannst auch ohne viel zu ändern Deine Schlüssel als vollständig erklären mit Hash::Util::lock_keys.

Ja natürlich. Aber ihr habt mich nicht ganz überzeugt, bzw.
ich sehe es nicht, warum ich das machen sollte...
Lapidar gesagt: Es stört ja nicht, ob in einem Hash, der ja
eigentlich sowieso nicht mehr geändert wird (zumindest sehe
ich das ein meinem Konzept ja so vor), ein Key mehr steht
oder nicht.

Oder: Welche "Gefahr" gehe ich denn ein, wenn ich meine
Hashes nicht locke ?

Die gleiche Gefahr, die beim Nichtverwenden von "use strict" und "my" besteht: du koenntest dich vertippen und der Zugriff auf ein Hash-Element laeuft ins Leere.