Hallo Dennis,
Nein, das Leuten zu verschweigen halte ich nicht für eine gute Idee - du weiß doch, sobald etwas verboten ist, wirds immer erst richtig interessant ;-)
eben deshalb: Was ich nicht weiß, macht mich nicht heiß. Anstatt jemanden zu warnen, "Bloß nicht die Sicherung überbrücken, das kann gefährlich sein", halte ich lieber meinen Mund und bringe denjenigen gar nicht erst auf solche Ideen.
Aber ich wollte eigehtlich mehr auf die "Konzeptschwäche" eingehen - ich halte das nämlich überhaupt nicht für eine Konzeptschwäche. Oder wie willst du ein Plugin-System realisieren, bei dem bestimmte Plugin-Dateien (z.B. aus einer Konfigurations-Datei) nachgeladen werden sollen?
Dafür ist das include-Prinzip nach meinem Verständnis sowieso der falsche Ansatz. Vielleicht liegt das an dem Weg, den ich in meiner Programmierer-Laufbahn genommen habe: Ich bin zunächst mit Sprachen wie Pascal, C und Assembler groß geworden. Da gibt es auch Includes, aber das spielt sich alles *vor* dem Compiler- bzw. Assemblerlauf ab. Das Ergebnis ist ein in sich abgeschlossenes Programmmodul, dessen Umfang der Programmierer exakt vorherbestimmt hat. Möchte ich während der Laufzeit weitere Module dynamisch dazuladen und ausführen, muss ich andere Techniken verwenden.
Aus der Compiler-Fraktion kommend, finde ich das liberale und dadurch komplexere Include-Prinzip von Scriptsprachen wie PHP zunächst mal bedenklich und werde tunlichst an meinen Gewohnheiten festhalten, nur Konstanten in den include-Anweisungen zu notieren - obwohl sie eigentlich bei der gebotenen Vorsicht ähnlich mächtig sind wie z.B. unter Windows das dynamische Nachladen von DLLs. Und ähnlich böse Stolperfallen produzieren können.
Im Gegensatz zu Windows-DLLs haben includierte Scripte in PHP allerdings leider keinen eigenen Adress- bzw. Namensraum. Eine saubere Modularisierung, wie sie für ein Plugin-Konzept wünschenswert wäre, ist dadurch IMHO sowieso nicht möglich.
So long,
Martin
"Drogen machen gleichgültig."
- "Na und? Mir doch egal."