Hallo perlianer,

schreibe grad an einem größeren projekt, und habe deswegen einige subs in module ausgelagert, die ich über use einbinde.

in enem der subs muß ich aber auf global deklarierte variablen des hauptprogrammes zurückgreifen, kann diese aber nicht beim aufruf der routine übergeben.

im hauptprogramm sieht das ganz grob so aus:


im parser-modul so:


die eval-klammer wird ausgewertet nach: if( $a_typ eq "link") oder if( $b_typ eq "link" ) etc.

da es nicht nur einige sondere recht viele  $xx_typ-deklarationen gibt, und je nach script-status anders aussehen, kann ich sie schlecht bei jedem aufruf neu übergeben.

gibt es eine möglichkeit, auf diese variablen in der art
    <aufrufer>$a_typ
zurückzugreifen ?

grüße aus heilbronn
siggi

Wenn du die Variablen aus dem "main"-Modul haben willst, dann must du es auch dazuschreiben. allso:

Aber warum nutzt du keinen Hash? In etwa so:


Die Verwendung wäre ohne "eval" möglich:


im allgemeinen wäre es auch günstig zu scheuen ob die Variable auch existiert, das ist bei einem Hash einfacher. (mittels "exists")

danke für die prompte antwort:-)

$main:: war genau was ich gesucht hab.

Die variante mit hash und exist funzt leider net, da die variable auf jeden fall existiert.
während der laufzeit wird ein array erzeugt, das z.B. @verkäufe_kundendaten heißt und wiederum eine "spalte des arrays @verkäufe ist. gleichzeitig mit der initialisierung dieser "spalte" wird die variable $verkäufe_kundendaten_typ angelegt, wo hinterlegt ist, ob die spalte vom typ text, zahl, oder link(auf eine andere liste/array @kundendaten) ist.

der select-string wird ausgewertet d.h.
select { verkäufe(id, pos, kundendaten, artikel, menge, VKsumme) } ;
wird mittels splitting des strings ausgewertet; macht die parser-subroutine. im laufe dieses prozesses wird der string verkäufe_kundendaten durch auflösen der klammer-ebenen generiert, und um zu entscheiden was damit geschehen soll, sein typ abgefragt.

daher benötige ich auch das eval.
aus verkäufe_kundendaten soll $verkäufe_kundendaten_typ ausgewertet werden, das auf jeden fall existiert.

hab auch schon ausprobiert, für jede liste bzw spalte einen hash anzulegen und typ etc auch da rein zu packen, aber auswertungen im sinne innerhalb eines hashs einen array zu haben und den dann noch über einen index, sprich die entsprechende zeile anzusprechen geht halt gar nicht. zudem array eines arrays über $array[$i][$j] bzw hash eines hashs funktionert aber hash eines arrays bzw umgekehrt schon recht problmatisch ist.

Danke trotzdem, hab das modell natürlich auch stark vereinfacht. Das ganze skript hat im moment auch weit über 600 zeilen, da ein socket-server, clientverwaltung und fehlerabfangroutinen etc auch noch drin stecken.

Grüße siggi

in einem modul variablen aus dem hauptprogramm zu benutzen ist unsauber;
es geht auch anders, z.b. ein config-namespace.
denn ein modul ist ja auch zur wiederverwendung gedacht, und damit
verhinderst du das.

und die variante mit eval ist auch unsauber, denn es geht auch anders.

edit:

nach einigem probieren; mit hash das sowohl arrays als auch weitere hashes enthält geht's doch :-)) und die ausertung mit eval entfällt auch.

zu $main::blah  :
wird später auch heißen


Da aber im monment noch alles WIP ist, sind noch nicht alle komponenten exakt verteilt. kann ebensogut sein, daß alle subs in einem modul drin bleiben.

grüße aus dem verschneiten heilbronn
siggi

Aus einem Modul auf Variablen ausserhalb des Moduls zugreifen?

Uuuuhhhhh, da schüttelt's mich.

Gruß, Doc

[quote=docsnyder,25.01.2007, 16:10]Aus einem Modul auf Variablen ausserhalb des Moduls zugreifen?

Uuuuhhhhh, da schüttelt's mich.[/quote]
:iro: Warum? Ist doch nett. Ganz besonders, wenn irgendwo im Hauptprogramm klammheimlich Vraiablen geändert werden. Schöner Seiteneffekt; taugt gut zur späteren kostenspieligen Fehlersuche oder ärgert garantiert die/den NachfolgerIn.

Da hat jemand denn Sinn von Funktionen und Modulen sehr missverstanden oder ist gar programmierfaul!?

Quote

Da hat jemand denn Sinn von Funktionen und Modulen sehr missverstanden oder ist gar programmierfaul!?

Yep! So etwas ist ein eklatanter Verstoß gegen jede Programmier-Philosophie. Die Errungenschaften der Informatik der letzten 40 Jahre werden damit mit Füssen getreten.

Na ja, jeder lernt dazu, und manche haben da eben etwas mehr Luft ...

Gruß, Doc

auf die gefahr hin,noch blöder zu scheinen al ich schon bin,
wie verwaltet ihr skripte mit weit über 600 zeilen, bzw, behaltet den überblick bei über 20 subs??

wie ich schon erwähnt habe ist momentan alles WIP und ich werde den ganzen aublauf so aufteilen, um solche konflikte mit variablen in pm und übergeordnetem skript durch geeignete namensräume und parmameterübergabe auszuschließen, aber bis ich weiß, wo welche variablen gebraucht werden, ist dies erst mal für mich erst mal ein praktikabler workaraound.

zudem es für mich wichtig ist, beim coden sowohl die aufrufende als auch die aufgerufene sub im blick zu haben; sprich: in einem editorfenster das hauptprogramm, daneben die entsprechende sub.
und bei so langen skripten permanent auf und abzuscrollen???

ich lasse mich gern eines besseren belehren, jedoch was spricht dagegen, ein modul xsdb ins hauptprogramm einzubinden, das seine eigenen module select_parse und where_parse etc. einbindet?
das von mir genannte "Modul" select_parse ist eine funktion des hauptprogramms xsdb, das je nach inhalt des übergebenen strings über eine haupt- und ein bündel von verzweigten subroutinen den string zerlegt und ein gültiges array zurückgibt.
das zweite "Modul" verfügt grundsätzlich über die gleichen subs, die machen aber im detail einige auswertungen nach etwas anderen kriterien. bzw liefern etwas andere rückgabewerte.

zur wiederverwendung ist xsdb in sich abgeschlossen, egal welches frontend oder clientverwaltung ... darauf zurückgreifen.

also was genau hab ich am sinn von funktionen bzw modulen falsch verstanden?? ( die frage ist ernst gemeint :-) )

und ja ich bin programmierfaul, da ich nicht einsehe, in diesem stadium des projekts festzulegen, welche daten bzw daten-attribute wann und an wen übergeben werden sollen, um eine saubere trennung zu gewährleisten; was jedoch nicht heißt, daß ich das nicht tun werde.

grüße siggi

Module sollten in sich geschlossen sein und nicht auf Variablen vom Hauptprogramm zugreifen. Bei Subs sollte man mit Übergabeparametern arbeiten

Was passiert wenn Du im Hauptprogramm eine Variable umbenennst. Dann musst Du in allen Modulen nachschauen, ob Du etwas ändern musst. Wenn Du mit Parametern arbeitest, passiert Dir das nicht...

Grundsätzlich ist es schon richtig, Subs zu gruppieren und in Module auszulagern. Es sollte aber schon "richtig" gemacht werden.