nicht angemeldet
Hi,
z.B. dbDoSomeStuff() fuer Routinen, die ein Database backend kapseln. Das ist im Prinzip schon ein objektorientierter Ansatz, es koennte genausogut $db->DoSomeStuff() heissen.
... oder bei mir eben db::do_some_stuff().
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.
Am Anfang sieht jedes Programm so aus - bis man sich die Mühe macht, es zu zerlegen ... wenn ich eine triviale Konfigurationsdatei einlesen will, dann ist mir das einen Modul wert - schon allein deshalb, weil es nicht auf derselben Abstraktionsebene liegt wie das Hauptprogramm.
Aufgeteilt habe ich das aus zwei Gruenden: Ich muss nicht in einer grossen Datei soviel rumscrollen
Yup - hätte es nicht Mehraufwand beim Installieren für Stefan bedeutet, dann hätte ich das Suchskript in ein Dutzend Dateien zerlegt.
Meine erwähnten knapp 20000 Perl-Zeilen bestehen aus 20 CGI-Unterverzeichnissen mit jeweils ca. 5-10 packages bzw. Hauptprogrammen.
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).
Und genau das geht eben *nicht* so gut mit einer Include-Datei, bei der Bezeichner mit irgendwas in dem neuen Programm kollidieren könnten, wie mit einer Package, wo definitiv alles disjunkt ist.
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?
Du müßtest den Export-Array halt überall mit "modulname::" prefixen - das sagt Dir der Interpreter, wenn Du ihn mit "use strict" lieb darum bittest. (Wenn nicht, dann greifst Du gnadenlos auf undefinierte Variablen zu ...)
DoSomeStuff $arg1, $arg2 return $err;
ist naemlich was anderes als
DoSomeStuff($arg1, $arg2) return $err;
(Ich sage nur Komma-Operator.)
Klar, aber man darf auch redundant klammern, beispielsweise hier den boolean expression ...
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.
Ich bin nicht sicher, aber ich denke, in irgendeiner älteren Perl-Version gab es *nur* diese Art des Aufrufs ...
Drittens natürlich immer "use strict".
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.
Dann präfixe einfach globale Variablen auch innerhalb ihres Moduls mit dem Modulnamen, und fertig ist die Laube. Lokale Variablen mußt Du dann halt alle deklarieren - dafür findest Du aber zuverlässig jeden Tippfehler in Variablennamen.
Ich wiederum habe beispielsweise "-w" bisher nicht benutzt ...
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?
Naja, ich habe halt das zuerst genommen, was ich aus Turbo-Pascal kannte ... (UNITED/XY auf meiner Homepage sind 33xyz lines in compilerbedingten 64 Modulen)