Calocybe: Sichtbarkeit von Funktionen

Beitrag lesen

Hi hi!

Ist für mich alles keineswegs schlüssig. Ich verwende generell nur packages, schon alleine weil ich den Überblick behalten will, wer in meinem name space herumsaut.

Den Ueberblick behalte ich schon noch, so gross ist das Programm nicht. Ausserdem kann man durch entsprechende Benennungen die Zugehoerigkeit klarstellen, z.B. dbDoSomeStuff() fuer Routinen, die ein Database backend kapseln. Das ist im Prinzip schon ein objektorientierter Ansatz, es koennte genausogut $db->DoSomeStuff() heissen.

Ich kann doch in packages "globale" Variablen definieren und diese von außerhalb mit packagename::variable ansprechen? Ich mache das dauernd - etwa bei einem Modul, der eine Datei parst und das Ergebnis als globalen Hash verfügbar macht. Reicht Dir das nicht?

Ich hab mir das mit den Modulen auch erst vor ein paar Tagen mal durchgelesen, deshalb habe ich das mal noch gelassen. Ausserdem wuerde das ueberhaupt nicht der gedachten Struktur entsprechen. Ich habe eben nur ein grosses Programm, keine einzelnen Module. Die einzelnen Teile sind mehrfach miteinander verwoben, es sind keine in sich abgeschlossenen Teile. Aufgeteilt habe ich das aus zwei Gruenden: Ich muss nicht in einer grossen Datei soviel rumscrollen und ich kann die Einzelteile genausogut in ein anderes Programm includen, das auf einen Grossteil aehnlicher Funktionalitaet zurueckgreifen muss (und genau das habe ich noch vor mir).

Aber davon mal abgesehen, wuerden die geschilderten Probleme nicht auftreten, wenn ich in jeder Datei noch eine package-Direktive und das Export-Array an den Anfang setzen wuerde?

Auch da bin ich - als Anwender von vielen verschiedenen Sprachen - viel zu ängstlich.
Erstens verwende ich generell nur Funktionsaufrufe mit Klammern, weil die eben wie Funktionsaufrufe in allen anderen mir geläufigen Sprachen aussehen.

Hatte ich am Anfang auch gemacht. Dann habe ich mich ein bisschen an die Perl-Schlampigkeit gewoehnt und die Klammern oft weggelassen. Seit dieser Erfahrung benutze ich sie nun auch wieder konsequent. Uebrigens kann man dadurch auch einige unerwartete Verhaltensweisen ausschliessen:
    DoSomeStuff $arg1, $arg2 return $err;
ist naemlich was anderes als
    DoSomeStuff($arg1, $arg2) return $err;
(Ich sage nur Komma-Operator.)

Zweitens verwende ich nur Aufrufe ohne den "&"-Operator davor, weil dieses das Prptotyping abschalten würde.

Der Sinn von dem Ding ist mir bis heute nicht klar - und noch dazu sieht's bloed aus.

Drittens natürlich immer "use strict". Perl ist ein übler Hacker-Slang, aber wenn man alles einschaltet, was die Sprache bietet, dann kann man richtig schöne Sachen damit schreiben (mein Projekt-Quelltext hat knapp 20000 lines of Perl code).

Perl ist mit Abstand die dreckigste Sprache, die ich kenne. Kein Wunder, wenn man bedenkt, wo das herkommt. Eine Mischung aus awk, sed, sh, c und anderen. Aber es hat eben eine maechtige Stringverarbeitung. Gib mir entsprechende Biblitheken fuer C und ich gehe wieder dort hin.

Als ich use strict ausprobiert habe, bin ich aber irgendwie gar nicht damit klargekommen. Ich habe keinen Weg gefunden, globale Variablen zu definieren. Da hab ich's eben gelassen. perl -w muss reichen. Aber ich werde diese Problematik am besten mal mit use strict 'refs' testen.

Ich kann es verschmerzen, eine Sprache nicht bis ins Letzte auszureizen - mir ist wichtiger, daß meine Programme funktionieren ... ;-)

Eigentlich sind packages ja schon der hoehere Level, das einfache includen der niedrigere. Also hast Du die Sprache doch schon viel mehr ausgereizt als ich, oder?

Calocybe