Hallo, Deine erste Aussage stimmt nicht, genau das ist ja der Vorteil auch von require, es wird eben nur einmal reingezogen, egal wie oft es im Code steht

"Note that the file will not be included twice under the same specified name."

sonst wäre es nicht gut, zb. bei Listenausgabe Plugins in einer Zeile einzusetzen, was ich mache. Wenn Du jetzt 100 Zeilen hast würde das 100x required werden, dem ist nicht.

Der grosse Vorteil von required ist halt, dass ist zur Laufzeit ausgewertet wird und so dynamisch eingesetzt werden kann, was bei use nur mit eval möglich ist. Das mache ich zwar auc hier und da, wenn grosse Module wie zb. Mime::Lite nur im Mailunterprogramm verwendet wird, was nur selten im Vergleich zu Rest aufgerufen wird, schön ist das aber nicht.

Das Problem mit den Plugins ist klar - aber das ist doch grundsätzlich ein OO-Vererbung Problem, wenn Du Dich nicht an den In- und Output hälst, dann geht der ganze quatsch nicht mehr. Das ist aber normal, da muss man halt aufpassen und genau schauen, was die Funktion macht, die man ersetzt. Aber es gibt einfach keine andere Möglichkeit core-Funktionen zu ersetzen und den Code update-fähig zu halten.

Ich habe mir ja jetzt für die Modul-methode entschieden, dann muss man wenigstens im EXPORT genau festlegen, was man überschreiben will.

Aber ich gebe zu, dass das ein Problem ist, aber ein allgemeines, wenn man überschreiben von Methoden durch einfach vererbungserweiterung zulässt, was aber heute die normale Vorgehensweise darstellt.

Die andere Möglichkeit sind HOOKs, was auch viele machen, da kannst Du aber halt nur ein bestimmten stellen bestimmte Dinge tun, zb. einen Hook nach dem Login etc.

In diesem ganzen Thema ist PHP leider extrem weit nach vorne gegangen, das es mir fast schon weh tut, wenn ich sehen muss, wie das hier umsetzen muss. Die haben jetzt richtig geniale Autoload-Funktionen und das OO-Thema ist echt gut umgesetzt, wenn sich die gängigen Design-Pattern anschaut und vergleicht, wie man das in beiden Sprachen jeweils umsetzt, dann ist teilweise wirklich nicht gut in Perl.

Was das grosse Problem ist, ist dass interface nur schwer umzusetzen sind. Normal programmierst Du so Plugins nur gegen ein interface, das interface schreibt vor, welche Subs dann Plugin haben muss und welche Variablen eine Sub haben muss mit Typ. Dadurch ist das nicht mehr so problematisch.

Ja schauen wir mal, für das Projekt ist das eine gute Lösung und der wo das einsetzt muss halt wissen was er macht.

Und für die komplette oo-implementierung wird das dann eh etwas anders gemacht.

Gruss M. Wolf