[quote=pq,05.06.2007, 12:05]das ändert nichts an der tatsache, dass das skript vermutlich als
mod_perl aufgerufen wird; nur so kann ich das verhalten erklären.
alles, was ich gesagt habe, gilt auch so.[/quote]
Heißt dies, dass man unter mod_perl nicht entwickeln/testen sollte, da ja etwas anderes dabei herauskommt als nachher in der produktiven Umgebung?
Welches andere Perl-System ist dann zu empfehlen?

Perl als CGI, nicht als modperl-Umgebung.

[quote=Barnabas,05.06.2007, 15:42]Heißt dies, dass man unter mod_perl nicht entwickeln/testen sollte, da ja etwas anderes dabei herauskommt als nachher in der produktiven Umgebung?[/quote]
nein, das heisst es nicht. mod_perl ist schon CGI vorzuziehen,
einfach weil es schneller ist. du musst halt deine subroutine ganz
einfach auslagern oder dort zumindest keine variable aus dem äußeren
scope des skripts verwenden.

[quote=pq,05.06.2007, 19:55]mod_perl ist schon CGI vorzuziehen,
einfach weil es schneller ist. du musst halt deine subroutine ganz
einfach auslagern oder dort zumindest keine variable aus dem äußeren
scope des skripts verwenden.[/quote]
Danke, so funktioniert es!

Ist diese Methode aber immer sinnvoll?
Auslagern kleinerer und nicht anderweitig gebrauchter Unterroutinen führt doch zu Overhead und Unübersichtlichkeit und erhöhtem Pflegeaufwand.
Und häufig hat man doch mehrere global definierte Variablen, die auch in der Unterroutine verwendet werden, die man dann alle übergeben und ggf. zurückliefern müsste.
Da es mir im Test nicht auf die letzte Millisekunde ankommt, wäre auch für mich der Zeitgewinn kein Argument.

Du könntest mich überzeugen, mit dem Argument, dass Deine vorgeschlagene Variante grundsätzlich das "bessere" Perl ist.

Ich habe inzwischen auch die Originalversion zum Laufen gebracht durch Änderung in
c:\xampp\apache\conf\extra\perl.conf

(PerlResponseHandler ModPerl::Registry ersetzt durch: PerlResponseHandler ModPerl::PerlRun)
Ich hab also jetzt beide Möglichkeiten.

[quote=Barnabas,06.06.2007, 10:38]Danke, so funktioniert es!

Ist diese Methode aber immer sinnvoll?[/quote]
ja

Quote

Auslagern kleinerer und nicht anderweitig gebrauchter Unterroutinen führt doch zu Overhead und Unübersichtlichkeit und erhöhtem Pflegeaufwand.

overhead im sinne von "perl muss eine datei mehr lesen"? dieser
"overhead" ist vernachlässigbar, zumal die vorteile überwiegen.
ich finde ein kleines script, dass möglichst viel in ein modul auslagert,
erheblich übersichtlicher.

Quote

Und häufig hat man doch mehrere global definierte Variablen, die auch in der Unterroutine verwendet werden, die man dann alle übergeben und ggf. zurückliefern müsste.

wenn man mehrere globale variablen hat, macht man was falsch.
man sollte möglichst wenig globale variablen benutzen, da sie im
endeffekt das programm schwer wartbar machen. man sollte möglichst
alle variablen als argumente übergeben. was dazu führt, dass man
zwar viele variablen als übergabeparameter hat, aber man kann ja
stattdessen auch einen hash verwenden.

Quote

Du könntest mich überzeugen, mit dem Argument, dass Deine vorgeschlagene Variante grundsätzlich das "bessere" Perl ist.

ist sie meiner meinung nach. da so ziemlich jedes programm irgendwann
wächst, ist eine frühere auslagerung eine gute sache. je später man
damit anfängt, desto mehr arbeit hat man.

Globale Variablen sind meistens schlecht, weil man dann nicht immer verfolgen kann wo etwas geändert wird! Deswegen möglichst mit Parametern arbeiten.

genau; mit der Verwendung von globalen Variablen holst du dir mehr oder weniger verdeckte Schnittstelle zu Subroutinen ins Haus, die die Analyse und Wartung von Code erschweren, gerade wenn ein Programm etwas groesser wird.

Besser lokale Variablen verwenden und alles als Parameter uebergeben, dann ist jede Subroutine eine BlackBox mit klaren Schnittstellen (Parameter, Rueckgabeparameter) und von aussen unabhaengig. Wenn du da drinnen was aenderst, braucht du nicht bei jeder Variable das ganze Programm ueberpruefen, ob die schon wo verwendet wird und ob du sie verwenden kannst, ohne eine andere Funktionalitaet zu behindern.
Und die lokalen Variablen immer im kleinstmoeglichen Block definieren, also nicht

sondern

usw.

Wenn man globale Variablen z.B. fuer Caching zu brauchen scheint, kann man fast immer zumindest Closures verwenden:


oder noch besser, mit Referenzen oder gar Objekten arbeiten