Variable in allen Programmen benötigt - wie?

[Kurti]

Hallo,
ich benötige eine Variable praktisch in allen Programmen (Hauptprogramm und Unterprogramme in externen Modulen).
Muss ich jetzt in jedem Funktionsaufruf dies Variable mitgeben oder kann ich eine Variable definieren, die überall bekannt ist?

[LX]

Du benötigst also eine globale Variable:

http://de.wikibooks.org/wiki/Perl-Programmierung:_G%C3%BCltigkeitsbereich_von_Variablen#Globale_Variablen

Gruß, LX

[Beat]

ich benötige eine Variable praktisch in allen Programmen (Hauptprogramm und Unterprogramme in externen Modulen).

Die Variable brauchst du wohl nicht in allen Programmen. Eher ihren Inhalt.

Muss ich jetzt in jedem Funktionsaufruf dies Variable mitgeben oder kann ich eine Variable definieren, die überall bekannt ist?

our erzeugt globale Variable, die von überall her mit
$main::varname erreichbar sind.

Das ist in meinen Augen aber kein guter Stil.

Auch ist die Frage offen, was deine Module mit der Variable tun dürfen.
Dürfen sie den Inhalt verändern. Oder sollen sie über einer Kopie des Inhalts arbeiten?

mfg Beat

[Kurti]

Auch ist die Frage offen, was deine Module mit der Variable tun dürfen.
Dürfen sie den Inhalt verändern. Oder sollen sie über einer Kopie des Inhalts arbeiten?

Sie dürfen die Variable verändern, genauer gesagt:
Ein Text wird immer wieder erweitert um hinten angehängte Textteile.
Am Programmende wird der Text ausgewertet.

[Beat]

Auch ist die Frage offen, was deine Module mit der Variable tun dürfen.
Dürfen sie den Inhalt verändern. Oder sollen sie über einer Kopie des Inhalts arbeiten?
Sie dürfen die Variable verändern, genauer gesagt:
Ein Text wird immer wieder erweitert um hinten angehängte Textteile.

$var .= somepack::somefunc();

tut was du beschreibst. Da ist kein Grund, dass du $var übergeben musst.

Am Programmende wird der Text ausgewertet.

Wenn du wirklich Text verändern willst:
Ich rate mal, um was es auch gehen könnte.

  
package main;  
  
my $htmlout;  
  
#Du gedenkst nun, dein bisheriges $htmlout in Funktionen zu erweitern.  
  
#Du gedenkst  
require somemod;  
#$htmlout = somemod::somefunc($htmlout);  
  
#Das ist erstmal böse. Dein Modul hat aller Rechte.  
#besser ist das  
  
$htmlout =~ s/<!--\s*SOME_ID\s*-->/somepackage::somemod()/e;  

Das heisst, deine Funktion kann nicht den ganzen bisherigen Ertrag verändern, sondern nur einen in diesem dafür vorgesehenen Platzhalter ersetzen.
Dein hauptprogramm muss eine Vorstellung von korrektem Umgang mit einer solchen Variable behalten.

mfg Beat

[Kurti]

#Du gedenkst nun, dein bisheriges $htmlout in Funktionen zu erweitern.

Ja!!

$htmlout =~ s/<!--\s*SOME_ID\s*-->/somepackage::somemod()/e;

Denke daran, dass ich schon mit $a .= "cc"; meine Probleme hatte.
Obiges Statement verstehe ich wahrscheinlich erst in x Monaten.

Aber selbst wenn ich obiges verstehen sollte, habe ich weitere Probleme:
1. Die Unterprogramme liefern schon unterschiedliche Werte zurück
2. Wenn ein schwerer Fehler in einem Unterprogramm auftritt, wird das Fehlerprogramm aufgerufen und dort benötige ich auch die $htmlout.

Gruß
Kurti

[Beat]

$htmlout =~ s/<!--\s*SOME_ID\s*-->/somepackage::somemod()/e;
Denke daran, dass ich schon mit $a .= "cc"; meine Probleme hatte.

nice perfect case!

Obiges Statement verstehe ich wahrscheinlich erst in x Monaten.

"here is a x" =~ s/x/u/;  
# results in "here is a u"  
  
"here is a <!-- SOME_ID -->" =~ s/<!--\s*SOME_ID\s*-->/u/;  
# results in "here is a u"  
  
sub func{ return "u"; }  
"here is a <!-- SOME_ID -->" =~ s/<!--\s*SOME_ID\s*-->/func()/e;  
# results in "here is a u"  
  
# s///e evaluiert die rechte Seite von s///  
  

Aber selbst wenn ich obiges verstehen sollte, habe ich weitere Probleme:

1. Die Unterprogramme liefern schon unterschiedliche Werte zurück
2. Wenn ein schwerer Fehler in einem Unterprogramm auftritt, wird das Fehlerprogramm aufgerufen und dort benötige ich auch die $htmlout.

Was ist mit deinen Funktionen falsch, dass sie immer den ganzen bisherigen Outbuffer kennen müssen?
Korrigiere deine Methode.

mfg Beat

[Kurti]

Hallo Beat,
danke für die Unterstützung.

sub func{ return "u"; }
"here is a <!-- SOME_ID -->" =~ s/<!--\s*SOME_ID\s*-->/func()/e;

results in "here is a u"

Hurra, habe ich verstanden, für das \s* könnte aber \s+ stehen, oder?

Was ist mit deinen Funktionen falsch, dass sie immer den ganzen bisherigen Outbuffer kennen müssen?

Wenn ich es mache, wie Du vorgeschlagen hast, dann nicht.
Dann muss nur das Fehlerprogramm und das Ausgabeprogramm den ganzen Outbuffer kennen. Das Fehlerprogramm wird aber dummerweise aus den Unterprogrammen aufgerufen.

Gruß
Kurti

[Beat]

Hurra, habe ich verstanden, für das \s* könnte aber \s+ stehen, oder?

Nein <!--xyz--> ist ein valider HTML Kommentar

Was ist mit deinen Funktionen falsch, dass sie immer den ganzen bisherigen Outbuffer kennen müssen?
Wenn ich es mache, wie Du vorgeschlagen hast, dann nicht.
Dann muss nur das Fehlerprogramm und das Ausgabeprogramm den ganzen Outbuffer kennen. Das Fehlerprogramm wird aber dummerweise aus den Unterprogrammen aufgerufen.

OK.
Reden wir über globale Variablen.
Es gibt globale Variablen, die Sinn machen.

package main;  
our $ERR =''; # grossbuchstaben hier.  
  
package somemod  
#wenn ein Fehler auftritt:  
$main::ERR .= "Errormessage";  
warn("Modul XY Zeile ".__LINE__." Meine Errormessage ");  
# schreibe es auch in die Errorlog.  
  
  
package main;  
$var =~ s/x/some::func()/e;  
$ERR and ... # hier rufe deinen Fehlerreporter auf.  

mfg Beat

[Kurti]

Hurra, habe ich verstanden, für das \s* könnte aber \s+ stehen, oder?

Nein <!--xyz--> ist ein valider HTML Kommentar

Habe ich es doch nicht verstanden? Muss da ein Kommentar stehen, der ersetzt wird?

Ich dachte jetzt so:
$htmlout .= "YXCVB"; # wobei YXCVB sonst nicht in $htmlout vorkommt
$htmlout =~ s/YXCVB/somepackage::somemod()/e;

warn("Modul XY Zeile ".__LINE__." Meine Errormessage ");

Wieder was gelernt (warn schreibt in die errorlog!)

package main;
$var =~ s/x/some::func()/e;
$ERR and ... # hier rufe deinen Fehlerreporter auf.

Aber was macht

$var =~ s/x/some::func()/e;

und ist folgendes ein if-Konstrukt der Art: if ($ERR and ....) {fehlerroutine()}

$ERR and ... # hier rufe deinen Fehlerreporter auf.

Ich hoffe, ich nerve Dich nicht zu sehr!?
Gruß
Kurti

[Beat]

Hurra, habe ich verstanden, für das \s* könnte aber \s+ stehen, oder?
Nein <!--xyz--> ist ein valider HTML Kommentar
Habe ich es doch nicht verstanden? Muss da ein Kommentar stehen, der ersetzt wird?

Ich dachte jetzt so:
$htmlout .= "YXCVB"; # wobei YXCVB sonst nicht in $htmlout vorkommt
$htmlout =~ s/YXCVB/somepackage::somemod()/e;

schon OK, aber da du hier hmloutput produzierst, könnte das Template wohl Anker enthalten, die nicht ersetzt werden.

my $bodytemplate = <<"TEMPLATE";
<body>
<!--InsertHeader-->
<!--InsertNavi-->
<!--InsertBody-->
<!--InsertSidebar-->
<!--InsertFooter-->
<!--InsertDebugMessage-->
</body>
TEMPLATE

Deshalb verwende ich HTML Kommentare als Platzhalter.
Falls eine Ersetzung nicht stattfindet, schadet es dem Ergebnis nicht.

warn("Modul XY Zeile ".__LINE__." Meine Errormessage ");
Wieder was gelernt (warn schreibt in die errorlog!)

Es ist der informative Brider von die().

Du solltest dir aber klar sein,
-- was sind fatale Fehler. -> die()
-- was sind Datenfehler aufgrund mangelhafter Daten -> warn()

package main;
$var =~ s/x/some::func()/e;
$ERR and ... # hier rufe deinen Fehlerreporter auf.

Aber was macht

$var =~ s/x/some::func()/e;

Es sucht nach einem x und ersetzt dieses durch den return von some::func()
Setze für x den geeigneten platzhalter ein.

und ist folgendes ein if-Konstrukt der Art: if ($ERR and ....) {fehlerroutine()}

$ERR and ... # hier rufe deinen Fehlerreporter auf.

1==1 and print "1 ist 1";
1==0 and print "Wenn ich drucke, ist die IT Welt kaputt";
1==1 or print "Die IT-Welt ist kaputt!";
1==1 and 1==0 and print "alles ist kaputt!";
1==0 or 1==1 and print "1 ist 1, was denn sonst";

and bindet enger als or.

mfg Beat

[Kurti]

Soweit klar, danke!

Aber was macht

$var =~ s/x/some::func()/e;

Es sucht nach einem x und ersetzt dieses durch den return von some::func()
Setze für x den geeigneten platzhalter ein.

Was das formal macht, war mir inzwischen klar.
Mir ist nur unklar, was die neue Variable $var im Zusammenhang:

package main;

our $ERR =''; # grossbuchstaben hier.

package somemod
#wenn ein Fehler auftritt:
$main::ERR .= "Errormessage";
warn("Modul XY Zeile ".LINE." Meine Errormessage ");

schreibe es auch in die Errorlog.

package main;
$var =~ s/x/some::func()/e;
$ERR and ... # hier rufe deinen Fehlerreporter auf.

>   
  
bedeutet.  
War mit $var die Variable $htmlout gemeint?

[Beat]

War mit $var die Variable $htmlout gemeint?

oder wie auch immer die Variable heisst, die dein Template speichert.

mfg Beat

[Kurti]

O.K.
Alles klar,
danke!

[CPAN]

Diese Art der Fehlerbehandlung ist Schrott. Ich kriege einen Würgereiz, wenn ich ein Modul einsetzen muss, das keine Exceptionobjekte im Ausnahme-/Fehlerfall erzeugt. Du tust niemandem einen Gefallen, so etwas als Beispiel zu lehren.

[Beat]

Diese Art der Fehlerbehandlung ist Schrott. Ich kriege einen Würgereiz, wenn ich ein Modul einsetzen muss, das keine Exceptionobjekte im Ausnahme-/Fehlerfall erzeugt.

Nicht Würgreiz. Du sollst sterben, oder nachdenken.

Du tust niemandem einen Gefallen, so etwas als Beispiel zu lehren.

Ich tue den Nutzern von Scripten einen Gefallen.

Es gibt verschiedene Arten von Fehlern.

Fehler, die fatal sind für die Programmlogik
die() in main
croak() in somemod
Es gibt Fehler, die durch mangelhafte Konfiguration oder Bedingung einer Nicht Perl API auftreten.
Dann willst du überleben und eine Information bereit halten.

mfg Beat

[CPAN]

Jemand, der im Jahr 2010 noch so einen Programmierstil propagiert, wie du es getan hast, ist nicht besser als Arzt, der nicht die Existenz und Wirkung von Bakterien anerkennt.

durch mangelhafte Konfiguration

Was du da beschreibst, sind tatsächlich Warnungen. Dafür gibt es die Objekte der Klasse warnings. Fehler (exception errors) gehören geworfen und sind, sofern nicht (durch vorzugsweise Try::Tiny) abgefangen, immer tödlich. So und nicht anders ist korrekte Terminologie und Kategorisierung.

Bitte beschäftige dich mit Diagnostikobjekten, ausgehend von $EVAL_ERROR und warnings::register. Ein Studium kontemporärer Perlmodule und des Buchs Perl Best Practices könnte auch nicht schaden, um dir die Nachteile einer Fehlermeldung zu verinnerlichen, die durch „action at a distance“ gesetzt wird.

[Kurti]

Jemand, der im Jahr 2010 noch so einen Programmierstil propagiert, wie du es getan hast, ist nicht besser als Arzt, der nicht die Existenz und Wirkung von Bakterien anerkennt.

Warum so aggressiv?
Diese Getöse hilft mir nicht weiter. An anderen herumzumäklen aber dem Hilfesuchenden selbst keine konkreten Vorschläge machen!
Gruß
Kurti

[Beat]

Jemand, der im Jahr 2010 noch so einen Programmierstil propagiert, wie du es getan hast, ist nicht besser als Arzt, der nicht die Existenz und Wirkung von Bakterien anerkennt.
Warum so aggressiv?
Diese Getöse hilft mir nicht weiter. An anderen herumzumäklen aber dem Hilfesuchenden selbst keine konkreten Vorschläge machen!

Naja
Vielleicht sollte man den Patienten erst mal anschauen, bevor man Antibiotika verschreibt.
Wir haben uns ja nicht über die Art der möglichen Fehler unterhalten, was sie für den programmablauf bedeuten etc.
Es gibt Fälle, wo try{}catch{} möglich ist. Jedoch fand ich besher noch keinen solchen Fall. Ich war mit eval{} or do{} auch gut bedient.

die();
Du setzt etwas voraus, das gut dokumentiert ist.
open( my $fh, "<", $file) or die($file. " is missing! $!");

croak() ist die Variante, die man in Modulen anwendet, um den Fehler aus der Sicht des callers (also dem use'enden Script ) auszugeben.

Du hast ein Plugin als Perl Modul, und dieses Modul wird durch eine API nun aufgerufen. However, wir wissen nicht, ob das Plugin auch existiert an seinem Ort.

Hier so ein Fall. Übergeben wird der name eines Plugins.

$plugin = "gibt es nicht";  
  
eval{  
	require( 'EHFPlugins/'.$plugin.'.pm' );  
	1;  
} or do {  
	# informative Fehler-Hinweise für den CMS Betreiber.  
	my $file = $Path{cgidir} . "EHFPlugins/". $plugin .'.pm';  
	( -e $file ) or return '<div class="warning">Plugin '.$plugin.'.pm konnte nicht gefunden werden.</div>';  
	( -r $file ) or return '<div class="warning">Plugin '.$plugin.'.pm hat keine Leserechte.</div>';  
	return '<div class="warning">Plugin '.$plugin  
	  . ' ('. $plugin .'.pm) konnte unerwartet nicht gestartet werden.<br>'  
	  .$@.'</div>';  
};

Das ist ein Fall wo ich eine klare Message an den Browser senden will.

Dann gibt es einfach Fälle wo du Userinput behandeln musst, der Userinput aber nicht valide ist.
Hier willst du zum Beispiel alle Fehler, die ein Formular betreffen, sammeln, und dann gemeinsam ausgeben, zusammen mit dem Formular mit den bisherigen Daten.

mfg Beat

[Kurti]

Hallo Beat,
so stelle ich mir Hilfe vor, auch wenn CPAN vielleicht wieder nörgeln wird.
Aber mir ist ein konkreter zweitbester Weg lieber als ein nebulöses Optimum, wobei ich das selbst ja nicht beurteilen kann!
Danke

[CPAN]

Es gibt Fälle, wo try{}catch{} möglich ist.

Es geht nicht um möglich (möglich ist es immer!), sondern um nötig.

Jedoch fand ich besher noch keinen solchen Fall. Ich war mit eval{} or do{} auch gut bedient.

Dieser Ansatz hat eine Schwachstelle, die mir persönlich schon zweimal in meiner Karriere begegnet ist; Stichpunkt $EVAL_ERROR im Destruktor. Dieses Problem zeigt seine hässlichen Fratze häufig genug, dass endgültig seine korrekte Lösung formell als Modul kodifiziert wurde.

Lass mich nun deinen Programmschnippsel kritisieren. Auf den ersten Blick sieht man gleich den größten Schwachpunkt, nämlich dass Fehlermeldungen als Funktionsergebnis zurückgegeben werden. Warum das furchtbar ist, ist auf dutzenden Seiten in Kapitel 13 von Perl Best Practices breitgetreten, werde ich hier nicht wiederholen. Dass die Fehlermeldungen auch noch Markup enthalten und somit die Trennung von View und Controller unterlaufen, ist das bizarre Sahnehäubchen. Ich wette, diese Meldungen werden zum Rendering durchgereicht und verbauen auch so die Möglichkeit zur I18n in der Zukunft. Du musst lernen, zu entkoppeln!

Der nächste Schwachpunkt ist, dass die Plugins an einem bestimmten Ort installiert werden müssen, anstatt das Standardsystem Perlincludepfad zu verwenden. Daraus ergibt sich auch, dass Plugins nicht hierarchisch gestaffelt werden können. Diesen Punkt werde ich nicht in meinem Gegenbeispiel ausbessern, um die Anwendung von Exceptionobjektattributen demonstrieren zu können.

Unter der Annahme, dass plötzlich die bereits vorhanden exquisiten Pluginsystem wie MooseX::Object::Pluggable oder Module::Pluggable aufhören zu existieren und ich sie nicht verwenden könnte, würde ich es viel robuster so schreiben:

  
package App::CMS::EHF;  
use Exception::Class (  
    'App::CMS::EHF::Exception::LoadPlugin' => {  
        fields => [qw(plugin_file_name does_not_exist not_readable)],  
        alias  => 'throw_load_plugin',  
    },  
);  
use Module::Load qw(load);  
use Moose qw();  
use MooseX::Params::Validate qw(validated_hash);  
use Moose::Util::TypeConstraints qw(subtype as where);  
use Try::Tiny qw(try catch);  
  
subtype 'App::CMS::EHF::Meta::Types::PluginName' => as 'Str' => where { /\A \w+ \z/msx };  
  
sub load_plugin {  
    my ($self, %params) = @_;  
    %params = validated_hash([%params], plugin_name => {isa => 'App::CMS::EHF::Meta::Types::PluginName',},);  
  
    my $plugin_file_name = $Path{cgidir} . "EHFPlugins/$params{plugin_name}.pm";  
  
    try {  
        load($plugin_file_name);  
    } catch {  
        if (!-e $plugin_file_name) {  
            throw_load_plugin plugin_file_name => $plugin_file_name, does_not_exist => 1  
        } elsif (!-r $plugin_file_name) {  
            throw_load_plugin plugin_file_name => $plugin_file_name, not_readable => 1  
        } else {  
            throw_load_plugin plugin_file_name => $plugin_file_name  
        }  
    }  
}  
  
package an_anderer_Stelle;  
my $stash;  
try {  
    ...->load_plugin(plugin_name => 'FooBarQuux');  
} catch {  
    if ($_->does_not_exist) {  
        $stash->{error_message} = sprintf('Plugin %s konnte nicht gefunden werden.', $_->plugin_file_name, );  
    } elsif ($_->not_readable) {  
        $stash->{error_message} = sprintf('Plugin %s hat keine Leserechte.', $_->plugin_file_name);  
    } else {  
        $stash->{error_message} = sprintf('Plugin %s konnte unerwartet nicht gestartet werden.', $_->plugin_file_name);  
        $stash->{error_trace} = $_->trace->as_string;  
    }  
};  
# $stash ins Templatingsystem übermitteln.  

[CPAN]

Hallo Kurti. Heute gebe ich dir mal einen Einblick in meine Gedankengänge. Ich hoffe, es ist nicht zu langweilig zu lesen.

Ich mäkele nicht an Beat rum (er könnte der Kaiser von China sein und das wär mir schnurzegal), sondern an seinem Code und Programmiertechniken/-stil. Das ist ein großer Unterschied.

Diese Sorte Mäkelei gehört in diesem Forum dazu; das Ziel ist schließlich nicht, nur einfach eine beliebige Antwort zu geben, die „gerade so“ funktioniert, sondern die beste Antwort unter Berücksichtigung von Umständen, an die der Fragende häufig gar nicht gedacht hat. Dazu ist Kritik nötig!

aber dem Hilfesuchenden selbst keine konkreten Vorschläge machen!

Wie du wünschst: https://forum.selfhtml.org/?t=194462&m=1302322

Ich habe deine Frage zuerst nicht beantwortet, weil sie leider unsäglich dämlich ist. Solche Sorte Fragen sind ein altbekanntes Phänomen und es wird erörtert in http://perl.plover.com/Questions.html, http://perl.plover.com/Questions3.html, http://perl.plover.com/varvarname.html (am Ende), http://www.perlmonks.org/index.pl?node_id=542341. Dafür kannst du nichts, viele Anfänger stellen keine guten Fragen, aber mit Erfahrung verbessert man sich; also bleibe am Ball.

Eine Antwort, die dich beim Worte nimmt und eine amateurhafte Lösung liefert, hast du in https://forum.selfhtml.org/?t=194462&m=1300497 ff. erhalten.

Wir stehen aber eigentlich vor einem XY-Problem (siehe vorherige Links). Du hast mich jetzt dazu gebracht, zu raten, was du eigentlich bezwecken willst, und damit dir die korrekte Antwort vom Standpunkt eines erfahrenen Programmierers zu geben. Wahrscheinlich gefällt sie dir überhaupt nicht, weil du etwas neues lernen musst und das total unbequem ist, das führt dann häufig zu sich automatisch entwickelnden Trotzreaktionen. Hat man alles schon tausendmal gesehen, in diesem Forum und anderswo. Womöglich hilft dir diese ausschweifende Ergänzung, dies leichter zu überwinden.

[Kurti]

Ich mäkele nicht an Beat rum (er könnte der Kaiser von China sein und das wär mir schnurzegal), sondern an seinem Code und Programmiertechniken/-stil. Das ist ein großer Unterschied.

Aber: Der Ton macht die Musik!

Ich habe deine Frage zuerst nicht beantwortet, weil sie leider unsäglich dämlich ist.

Dämlich sind nicht Fragen, sondern - wie man hier sieht - die Antworten.
Ein Anfänger kann leider keine so intelligente Fragen stellen, dass Du ihm gar nicht zu antworten brauchst!

[hotti]

moin,

Muss ich jetzt in jedem Funktionsaufruf dies Variable mitgeben oder kann ich eine Variable definieren, die überall bekannt ist?

Weder noch. Der hash %ENV ist bereits definiert.

Du musst bei solchen globalen Gechichten jedoch immer aufpassen, dass Du die Übersicht nicht verlierst. Ich mache das so, dass ich in meinem Basismodul, was ich praktisch überall einbinde, ganz oben einen Kommentarblock babe, gut sichtbar und besser sichtbar als eine etwaige Zeile use vars qw(%foo @bar);

Hotti

[Beat]

Muss ich jetzt in jedem Funktionsaufruf dies Variable mitgeben oder kann ich eine Variable definieren, die überall bekannt ist?

Weder noch. Der hash %ENV ist bereits definiert.

$ENV hat den Status einer Müllhalde. Das ist definitiv kein Speicherort.

mfg Beat

[CPAN]

Dies ist mit ziemlicher Sicherheit der falsche Ansatz, und die Antworten in diesem Thread, die in diese Richtung gehen, lösen somit die Problemstellung nicht auf die richtige Art und Weise.

Ich rate, du möchtest Vorlagen (Templating) benutzen. Ich empfehle Text::Template, da fällt der Einstieg nicht schwer, und Template::Toolkit, welches das Standardvorlagensystem in der Perlwelt und auch sehr mächtig ist. So vermeidest du die fiesen Konsequenzen, die eine global gültiges, veränderliches Datum mit sich zieht. Dazu siehe die Abschnitte in http://perl.plover.com/varvarname3.html, die das Wort trend enthalten.