Klassen Konstanten zu laufzeit definieren?

[MB]

moin Community,

ich hab versucht klassen konstanten dynamisch zur laufzeit zu erstellen, was leider Fehlgeschlagen ist 😕. Zur Frage: Kann man überhaupt das machen? Geht das? wenn nein: Alternative?

Ich hab daher versucht sowas zumachen, schlug leider aber auch fehl. Methoden bei property-Deklaration in Klassen geht bekanntlich nicht.

class Paths {
  private static $root; // hilfsvariable
  private function __() { // automatisches 
    self::$root = dirname( _DIR__ );
  }
  const ROOT = self::$root;
}

Zur Arbeit: Ich habe das gesamte Verzeichnis des Frameworks gescant und dann in nem Array die Pfade gespeichert. Eine andere Klasse hat dann dieses Array genommen und daraus Konstanten mit define() erzeugt aber keine Klassenkonstanten :/. schön wäre es mit dynamisch erzeugtem Path::ROOT und nicht mit PATH_ROOTarbeiten zu können. Ich sehe die Klassen-Konstanten als eine Abhängigkeit zwischen Konstante und Klasse, und in Konstanten die mit define() erzeugt wurde ist diese schöne Abhängigkeit nicht vorhanden.

Ich krig einfach die Pfad-Konstanten als Initalisierung nicht richtig zustande, die dann für die Autoloader-Klasse (intern spl_autoload_register()) zurverfügung stehen. Ich muss ja vorab, im Entrypoint, Pfade konstruieren zu den Dateien navigieren die wiederum Pfade als Klasse Konstruieren.

Die Frameworks die ich mir angeschaut habe nutzen Composer und andere sehr statisch mit 'require'.

vlg MB

[pl]

Bei meinem PHP Framework habe ich das genauso gemacht wie das in Perl seit Urzeiten üblich ist:

Die Klassenhierachie wird in der Verzeichnisstruktur abgebildet und der Name einer Klasse beeinhaltet den Pfad zur Datei einschließlich Dateiname ab dem Verzeichnis welches initial für die ganze Library festgelegt wurde. Beispiel: class Admin_Explorer ist die Datei Explorer.php im Verzeichnis Admin das sich direkt unterhalb des [include] Verzeichnisses befindet. Dann klappts auch mit der Automatisierung.

Schönen Sonntag!

[MB]

Moin pl,

Die Klassenhierachie wird in der Verzeichnisstruktur abgebildet und der Name einer Klasse beeinhaltet den Pfad zur Datei einschließlich Dateiname ab dem Verzeichnis welches initial für die ganze Library festgelegt wurde. Beispiel: class Admin_Explorer ist die Datei Explorer.php im Verzeichnis Admin das sich direkt unterhalb des [include] Verzeichnisses befindet. Dann klappts auch mit der Automatisierung.

schönes Muster wäre auch mein Ziel gewesen aber wofür gibts Autoload wenn man es nicht nutzt. Du meinst doch das inkludieren über eine Schleife ohne Autoload oder?Klappt das auch in komplexen strukturen des Frameworks?

vlg MB

[dedlfix]

Tach!

Beispiel: class Admin_Explorer ist die Datei Explorer.php im Verzeichnis Admin das sich direkt unterhalb des [include] Verzeichnisses befindet.

schönes Muster wäre auch mein Ziel gewesen aber wofür gibts Autoload wenn man es nicht nutzt. Du meinst doch das inkludieren über eine Schleife ohne Autoload oder?

Der Autoloader befreit dich nur davon, in jeder Datei eine Latte von require/include-Statements anführen zu müssen. Du brauchst ihn in jedem Fall, wenn du das vermeiden möchtest. Wie der Autoloader dann die physischen Dateien zu den Klassennamen findet, steht auf einem anderen Blatt. Üblich ist die Vorgehensweise, dass der Dateiname inklusive Pfad aus dem Klassennamen und gegebenenfalls Namespaces gebildet werden kann.

Wenn nun eine Klasse benötigt wird, hat man ein Stück Programmcode zu durchlaufen, der einen Pfadnamen aus dem Klassennamen erstellt und dann eine I/O-Operation für den eigentlichen Zugriff. Wenn du hingegen bei jedem Scriptaufruf erstmal tausend I/O-Operationen machen musst, um alle Dateien zu ermitteln, und dann noch bei jeder Suche nach der Klassendatei durch das Array laufen musst, ist das sicherlich nicht die bessere Methode.

Klappt das auch in komplexen strukturen des Frameworks?

Das klappt nur so gut, wie du dich an die Regeln für Benamsung hältst, die auch der Autoloader kennt. Wenn das übereinstimmt, ist die Komplexität aber kein negatives Kriterium diesbezüglich.

dedlfix.

[pl]

Hi MB,

interessanter als Klassen automatisch zu laden, ist das automatische Laden von Methoden aus dem Dateisystem, die erst dann compiliert werden wenn sie gebraucht werden. Damit wird dein Code übersichtlicher, effizienter und du vermeidest Redundanzen.

Natürlich können solche Methoden auch selbst weitere Module und Code einbinden. Wichtig ist der Performanze wegen, die Dateien solcher Methoden nicht bei jedem Aufruf neu zu compilieren sondern nur einmal beim ersten Aufruf.

Einmal den include Path gesetzt, findet PHP auch die richtige Datei zur Methode die im Dateinamen den Namen der Methode codiert hat.

MfG

[dedlfix]

Tach!

interessanter als Klassen automatisch zu laden, ist das automatische Laden von Methoden aus dem Dateisystem, die erst dann compiliert werden wenn sie gebraucht werden.

Das ist nicht der Weg, der PHP-üblich ist. Man kann das zwar erreichen, aber dazu braucht man die Extension runkit, die nicht zum Lieferumfang gehört.

Damit wird dein Code übersichtlicher, effizienter und du vermeidest Redundanzen.

Vermutlich ist der Aufwand, die entsprechende Datei zu suchen und zu laden und die Methode einzubinden größer, als den Code gleich mit zu compilieren.

Zudem, wenn man auf die Idee kommt, Methoden optional nachladbar zu machen, sollte man sich eher fragen, ob das überhaupt eine Methode der Klasse sein muss oder nicht vielleicht eine eigenständige Funktionalität ist, der man lieber eine eigene Klasse spendiert. Dann könnte man nämlich diese mit dem sowieso schon vorhandenen Autoloader genauso wie alle anderen Klassen laden lassen und braucht keine zwei Mechanismen.

Natürlich können solche Methoden auch selbst weitere Module und Code einbinden. Wichtig ist der Performanze wegen, die Dateien solcher Methoden nicht bei jedem Aufruf neu zu compilieren sondern nur einmal beim ersten Aufruf.

Das geht vielleicht mit Perl. Thema ist aber PHP. Der Kompilierprozess ist nicht beeinflussbar. Mittlerweile gibt es auch einen eingebauten OpCode-Cache, der die Notwendigkeit des erneuten Kompilieres bei jedem Script-Aufruf überflüssig macht. Aber auch für den gibt es keine Möglichkeit, ihn zu Fuß zu steuern, der arbeitet ganz von allein im Hintergrund.

dedlfix.

[pl]

Das ist nicht der Weg, der PHP-üblich ist.

So!? Das bestimmt Du wohl oder was!?

Man kann das zwar erreichen, aber dazu braucht man die Extension runkit, die nicht zum Lieferumfang gehört.

Selbstverständlich gehört die Funktion __call() zum Lieferumfang! Informiere dich gefälligst!

Vermutlich ist der Aufwand, die entsprechende Datei zu suchen und zu laden und die Methode einzubinden größer, als den Code gleich mit zu compilieren.

Völliger Blödsinn Deine Vermutung! Wie ich schrieb, wird der include Path gesetzt und warum sollte ein Haufen Code ständig compiliert werden wenn er gar nicht gebaucht wird!?

Zudem, wenn man auf die Idee kommt, Methoden optional nachladbar zu machen, sollte man sich eher fragen, ob das überhaupt eine Methode der Klasse sein muss oder...

Auch Quatsch. Eine Klasse allein bewegt nämlich gar nichts. Auf die Methode kommt es an. Und selbstverständlich sind ausgelagerte Methoden keine Klassenmethoden sondern Instanzmethoden, ist dir der Unterschied eigentlich klar?

Das geht vielleicht mit Perl. Thema ist aber PHP. Der Kompilierprozess ist nicht beeinflussbar. Mittlerweile gibt es auch einen eingebauten OpCode-Cache, der die Notwendigkeit des erneuten Kompilieres bei jedem Script-Aufruf überflüssig macht. Aber auch für den gibt es keine Möglichkeit, ihn zu Fuß zu steuern, der arbeitet ganz von allein im Hintergrund.

Selbstverständlich kann man das auch in PHP so steuern, daß eine Lazy-Load-Methode jedesmal neu compiliert wird oder nur einmal beim ersten Aufruf. Also man kann in PHP den Codecache nutzen oder nicht.

Im Übrigen: Auch in Perl gibt es die Möglichkeit, Klassen automatisch zu laden. Es ist nur so, dass sich das in der Breite nicht durchgesetzt hat weil es unsinnig ist und die Lesbarkeit von Code verschleiert. Deswegen schrieb ich ja eingangs, daß es interessanter ist, weil effizienter, anstelle von Klassen eben Methoden nachzuladen. "Code durch Teilen effizienter machen" geht sogar in Richtung Unit-Tests, es ist nämlich so, dass ausgelagerte Methoden zwar Instanzmethoden sind, aber sie sind nicht an eine fest vorgegebene Klasse gebunden (es sei denn man manifestiert das). Damit sind solche Methoden über eine Attrappe aufrufbar (Mock) und dass man damit Redundanzen vermeiden kann schrieb ich ja auch.

Und ja, natürlich können solche Methoden auch selbst weitere Module und Code einbinden. Vielleicht hast Du ja mal was von einer Factory gehört.

Schönen Tach noch!

[dedlfix]

Tach!

Deine Aussagen stimmen größtenteils nicht mit der Arbeitsweise von PHP überein. Zudem ist deine Diskussionskultur ziemlich daneben. Statt lediglich fachlich auf meine Aussagen einzugehen, greifst du mich an. Darauf habe ich keine Lust und deshalb lass ich deine Antwort diesmal ohne fachliche Erwiderung.

dedlfix.

[pl]

Eigentlich wollte ich Dir überhaupt nicht anworten. Aber Dein Beitrag war fachlich dermaßen daneben, deswegen musste ich das tun. Du hast überhaupt keine Ahnung von Laufzeitoptimierung und der Begriff der Factory ist Dir ebenfalls unbekannt. Natürlich kann man das alles auch mit PHP machen, wenn auch umständlicher als mit Perl.

Wesentlich ist, in Perl wie in PHP, den include Path richtig zu setzen und nicht etwa anfangen eine eigene Suchfunktion für Code-Dateien zu basteln.

Im Übrigen greife ich Dich nicht persönlich an sondern zeige Dir nur worin Deine fachlichen Defizite bestehen. Und dass es Dir erheblich an Erfahrung mangelt habe ich Dir auch schon mehrfach mitgeteilt. Mit dem include Path und einer zweckmäßigen Nomenklatur ergeben sich nämlich eine ganze Menge Abhängikeiten, angefangen von einem aufgeräumten Code (-> Teamarbeit) über Laufzeitoptimierung bis hin zu Unittests und Qualitätsicherung. Selbst eine testgetriebene Entwicklung steckt da mit drin.

Es kann gut sein, dass Du mit diesem Komplex total überfordert bist. Nichtsdestoweniger würde ich mich freuen, wenn Du aus diesem Thread was lernen tätest. Insbesondere den Respekt gegenüber Kollegen die neben fachlicher Kompetenz auch ihre Erfahrung hier einbringen. MfG

[ManFree]

Im Übrigen greife ich Dich nicht persönlich an sondern zeige Dir nur worin Deine fachlichen Defizite bestehen.

Insbesondere den Respekt gegenüber Kollegen die neben fachlicher Kompetenz auch ihre Erfahrung hier einbringen.

Soso.

So!? Das bestimmt Du wohl oder was!?

Informiere dich gefälligst!

Völliger Blödsinn Deine Vermutung!

Auch Quatsch.

ist dir der Unterschied eigentlich klar?

fachlich dermaßen daneben

Du hast überhaupt keine Ahnung von Laufzeitoptimierung

dass es Dir erheblich an Erfahrung mangelt

Es kann gut sein, dass Du mit diesem Komplex total überfordert bist.

Liebes Forum,

was muss eigentlich noch geschehen, damit diese miese Person endlich mal gesperrt(*) wird? Wie lange wollt ihr das noch mitmachen? Wieviele etliche sinnbefreite Dikussionen mit einer diskussionsresistenten und herablassenden Person sollen denn noch geführt werden?

Es ist ABSOLUT SINNLOS auch nur einen einzigen Satz mit dieser Person auszutauschen. Das sollte doch mittlerweile hinlänglich bekannt sein.

Eure Bekehrungen in allen Ehren, aber ist denn nicht langsam echt mal genug? In der Zeit kann doch jeder hier was sinnvolles machen.. eine Library entwickeln, in die Kneipe gehen, mit den Kindern spielen, gemeinnützige Arbeit leisten etc. pp.

Dieses Forum hat mittlerweile so viel Müll durch diese Person aufgesammelt, das ist doch hier keine Ego-Show. Jeder xte Thread dreht sich gefühlt nur noch um Worthülsen, Vorwürfe, Besserwissereien, Boshaftigkeit, Herablassung und absoluter Ahnungslosigkeit.

Wirklich fragende Grüße, Kris

(*) Ja, ich weiß, das ist immer das allerletzte Mittel. Aber mal ehrlich: Was soll denn noch geschehen? Ab wann soll die Reisleine gezogen werden?

[Matthias Apsel]

Hallo ManFree,

Informiere dich gefälligst!

[…]

Es kann gut sein, dass Du mit diesem Komplex total überfordert bist.

diese miese Person

diskussionsresistenten und herablassenden Person

Es ist ABSOLUT SINNLOS auch nur einen einzigen Satz mit dieser Person auszutauschen.

Müll durch diese Person aufgesammelt

Du solltest nicht gleiches mit gleichem vergelten. Rolf ist speziell, ja, aber er ist selten ausfallend, wie in dem Beitrag. (Auch dauerhaft) Unsinn zu schreiben, rechtfertigt keine Sperre. Außerdem müsste man manuell jeden seiner Beiträge löschen und einen solchen Kleinkrieg möchte ich nicht spielen müssen.

Bis demnächst
Matthias

[ManFree]

Hallo Matthias,

ich frage mich, warum du

diskussionsresistent und herablassend

als negative Beispiele meines Postings nimmst, wobei dieses doch über die letzten Jahre das am meist kritisierte Verhalten der Person ist? Möchtest du das etwa abstreiten?

diese miese Person

Ich schreibe mies, du schreibst speziell - und beides meint das Gleiche. Das eine natürlich politisch korrekter..

Es ist ABSOLUT SINNLOS [..]

Siehe oben. Mir ist kein einizges Posting bekannt, in dem Hotti sein fachlich inkorrektes Posting nach überzeugenden Argumenten der Gegenseite zurückgezogen hat. Nein, vielmehr wird er dann ausfallen und beleidigend.

Müll durch diese Person aufgesammelt

Ja, das Wort Müll ist abermals politisch unkorrekt. Aber das ändert ja nichts an der Tatsache.

Außerdem müsste man manuell jeden seiner Beiträge löschen und einen solchen Kleinkrieg möchte ich nicht spielen müssen.

Die Qualität dieses Forums hat sich also hinter den Beiträgen von Hotti anzusiedeln. Und die Sicherheit, dass Benutzer hier von dieser Person so häufig herablassend behandelt werden, ist also auch nicht relevant.

Interessante Ansicht hast du.

VG ManFree

[Christian Kruse]

Hallo ManFree,

diese miese Person Ich schreibe mies, du schreibst speziell - und beides meint das Gleiche. Das eine natürlich politisch korrekter..

Das hat mit PoCo nichts zu tun. „Formuliere höflich und wertschätzend“ ist Teil der Charta.

Es ist ABSOLUT SINNLOS [..] Siehe oben. Mir ist kein einizges Posting bekannt, in dem Hotti sein fachlich inkorrektes Posting nach überzeugenden Argumenten der Gegenseite zurückgezogen hat. Nein, vielmehr wird er dann ausfallen und beleidigend.

Deshalb bekommt er auch des öfteren Kontra. Und wir mussten auch schon so einige Postings löschen. Auch dieses Posting hätte ich gelöscht, wenn ich es früher gesehen hätte; und hätte es einen User betroffen und keinen Moderator, hätte ich es trotzdem gelöscht. In diesem Fall aber wäre Dedlfix als Moderator in der Lage gewesen, das Posting selber zu löschen, und hat sich als Betroffener dagegen entschieden. Das ist dann für mich ein klares Signal, dass eine Löschung vom Betroffenen nicht gewünscht ist.

Außerdem müsste man manuell jeden seiner Beiträge löschen und einen solchen Kleinkrieg möchte ich nicht spielen müssen. Die Qualität dieses Forums hat sich also hinter den Beiträgen von Hotti anzusiedeln.

Eher so: dieses Forum muss genug Toleranz aufbringen, um auch Leute wie Hotti auszuhalten und ggfls korrigierend einzugreifen.

Und die Sicherheit, dass Benutzer hier von dieser Person so häufig herablassend behandelt werden, ist also auch nicht relevant.

Das wäre dann so ein Fall, wo man korrigierend eingreifen müsste.

LG,
CK

[ManFree]

Hallo CK,

Das hat mit PoCo nichts zu tun. „Formuliere höflich und wertschätzend“ ist Teil der Charta.

Sieh einer an!

Deshalb bekommt er auch des öfteren Kontra.

Naja, das ist eher eine Frage der Zeit. Es deutet sich ja bereits schon an, dass immer weniger Leute die Lust haben, auf diesen ganzen **charta** von Hotti einzugehen.

Und wir mussten auch schon so einige Postings löschen. Auch dieses Posting hätte ich gelöscht, wenn ich es früher gesehen hätte; und hätte es einen User betroffen und keinen Moderator, hätte ich es trotzdem gelöscht.

Fair enough.

In diesem Fall aber wäre Dedlfix als Moderator in der Lage gewesen, das Posting selber zu löschen, und hat sich als Betroffener dagegen entschieden. Das ist dann für mich ein klares Signal, dass eine Löschung vom Betroffenen nicht gewünscht ist.

Logischerweise sollte dann die Charta erweitert werden, dass Moderatoren beleidigt werden dürfen.

Und Nicht-Stammuser (also die, die über Suchmaschinen ins Archiv gelangen oder gelegentlich im Forum vorbeischauen) wissen dann woher genau, dass es sich um einen Moderator handelt?

Und woher wissen diese, dass dies ja eigentlich nicht der Ton hier ist?

Und wenn man auf diesen Beitrag in ein paar Jahren stößt, dann ist immernoch sichergestellt, dass Matthias weiterhin Moderator ist?

Eher so: dieses Forum muss genug Toleranz aufbringen, um auch Leute wie Hotti auszuhalten und ggfls korrigierend einzugreifen.

Das ganze klingt für mich ehrlich gesagt nicht gerade nach einem Plan. Toleranz ist natürlich immer schön gesagt.

Das wäre dann so ein Fall, wo man korrigierend eingreifen müsste.

Schonmal darüber nachgedacht, dass vielleicht einige potentielle Neu-User gar nicht mehr erst diesem Forum beitreten oder gar Fragen stellen wollen, weil hier immer häufiger persönlicher angegriffen und fachlicher **charta** verbreitet wird?

VG ManFee

[ManFree]

Nun gut, keine Antwort ist auch eine Antwort. Vielen Dank für die Stellungnahme oder so.

[Orlok]

Bei dem Titel hatte ich mir von dem Beitrag irgendwie mehr erhofft.

[dedlfix]

Tach!

ich hab versucht klassen konstanten dynamisch zur laufzeit zu erstellen, was leider Fehlgeschlagen ist 😕. Zur Frage: Kann man überhaupt das machen? Geht das? wenn nein: Alternative?

Der Wert einer Konstante muss zum Kompilierzeitpunkt feststehen. Es gibt aber statische Elemente (Keyword static), die einmalig an der Klasse sitzen statt an jedem Objekt einzeln und zur Laufzeit geändert werden können.

class Paths {
  private static $root; // hilfsvariable
  private function __() { // automatisches 
    self::$root = dirname( _DIR__ );
  }
  const ROOT = self::$root;
}

Dein Konstrukt geht davon aus, dass der Code in der Reihenfoge der Notation ausgeführt. Das ist nicht der Fall.

Wenn du $root auf public umstellst und das CONST weglässt hast du dein Ziel erreicht. Soll $root aber unbedingt gegen Schreibzugriffe geschützt sein, dann lass es private und erstell eine public static Zugriffsfunktion, die den Wert ausliest und zurückgibt.

Zur Arbeit: Ich habe das gesamte Verzeichnis des Frameworks gescant und dann in nem Array die Pfade gespeichert. Eine andere Klasse hat dann dieses Array genommen und daraus Konstanten mit define() erzeugt aber keine Klassenkonstanten :/.

Und dann? Woher weiß der Code nun, welche Konstanten definiert sind? Was sind das eigentlich für Pfade, die es da zur Laufzeit zu finden gilt?

Die Frameworks die ich mir angeschaut habe nutzen Composer und andere sehr statisch mit 'require'.

Composer ist kein Pfadverwaltung sondern eine Paketverwaltung, um Pakete von anderen in seiner Software zu verwenden. Dass diese Pakete irgendwie aufgerufen und deren Code inkludiert werden muss, ist auch klar, dazu braucht es einen Lademechanismus.

dedlfix.

[MB]

moin dedlfix,

Soll $root aber unbedingt gegen Schreibzugriffe geschützt sein, dann lass es private und erstell eine public static Zugriffsfunktion, die den Wert ausliest und zurückgibt.

Sprichst du über Properties wie Constanten oder Methoden? Wenn du über Properties redest dann gib mir n Beispiel damit ich das nachvollziehen kann.

Und dann? Woher weiß der Code nun, welche Konstanten definiert sind?

Wenn die Klasse die Pfad Konstanten definiert hat, kann ich die Konstanten zu Laufzeit in einem Pfad-Array speichern, sodass es der Autoload-Klasse zur Verfügung gestellt wird. Soweit bin ich aber noch nicht gegangen. Erst mal nachfragen. Ich kann get_defined_constants() verwenden, was aber dann alle konstanten betrifft auch die, die nich für Pfade stehen.

Was sind das eigentlich für Pfade, die es da zur Laufzeit zu finden gilt?

Na Verzeichnisspfade zu den einzelne PHP's (z.B. PATH_APP_CONTROLLERS oder PHP_SYSTEM_CORE). So muss der Autoloader nicht ständig Pfade ändern und dann prüfen (z.B. $controller = ROOT .DS .APP .CONTROLLER .DS . $controller .'.php';) sonder einfach über eine foreach()-Schleife laufen bis er die sache findet oder nicht mit

Composer ist kein Pfadverwaltung sondern eine Paketverwaltung, um Pakete von anderen in seiner Software zu verwenden.

Ok ich habe mich nicht mit composer beschäftigt Danke dir für die Info.

vlg

[dedlfix]

Tach!

Soll $root aber unbedingt gegen Schreibzugriffe geschützt sein, dann lass es private und erstell eine public static Zugriffsfunktion, die den Wert ausliest und zurückgibt.

Sprichst du über Properties wie Constanten oder Methoden? Wenn du über Properties redest dann gib mir n Beispiel damit ich das nachvollziehen kann.

Ich spreche über Zugriffsmodifizierer (public/private) und das Keyword static. Mit static kann man Mitglieder (Eigenschaften und Methoden) an die Klasse binden statt dass sie in jeder einzelnen Instanz separat leben. Statt Klassenkonstanten, die zum Kompilierzeitpunkt feststehen müssen, kannst du eine statische Property nehmen, die du zur Laufzeit befüllen kannst. Allerdings ist diese im Gegensatz zu Klassenkonstanten änderbar. Deswegen als private verstecken. Damit kann man sie zwar immer noch innerhalb der Klasse und deren Instanzen ändern, aber immerhin nicht mehr von überall her, wie das bei public der Fall wäre.

class Foo {
  private static $bar;

  public static GetBar() {
    return self::$bar;
  }
}

Wenn $bar ein skalarer Wert oder ein Array ist, dann bekommst du eine Kopie von GetBar(). Da Objekte aber ohne clone als Referenz übegeben werden, würde der originale Inhalt geändert werden können.

Und dann? Woher weiß der Code nun, welche Konstanten definiert sind?

Ich kann get_defined_constants() verwenden, was aber dann alle konstanten betrifft auch die, die nich für Pfade stehen.

Eben, schon wird's Mist. Dann lieber ein Array, in dem nur die gefragten Daten stehen und nicht noch nebenbei etwas anderes dazukommen kann.

So muss der Autoloader nicht ständig Pfade ändern und dann prüfen (z.B. $controller = ROOT .DS .APP .CONTROLLER .DS . $controller .'.php';) sonder einfach über eine foreach()-Schleife laufen bis er die sache findet oder nicht

Das Zusammenbauen des Pfades aus einer gleichbleibenden Anzahl von Einzelteilen ist immer gleich teuer. Das Iterieren über ein Array wird mit zunehmender Größe teurer, besonders wenn der Eintrag weit hinten steht. Was aber im Vergleich zur anderen Methode günstiger ist, müssen Messungen zeigen.

Wenn du dir das aus Optimierungsgründen überlegt hast, dann vergiss diese Überlegung, solange du nicht durch Messungen ihre Richtigkeit bestätigt hast.

dedlfix.

[Rolf B]

Hallo MB,

kannst Du mir mal beiläufig verraten, worum es sich bei __ handelt? Es liest sich wie ein Klassen-Initializer, aber mir war bisher nicht bekannt, dass PHP so etwas hätte und ich finde auch nichts dazu in der PHP Doku. Onkel Bing Googlesby führt mich auch nicht zu sinnvollen Dingen.

Bin ich zu blind, oder ist das ein Feature einer Erweiterung, die Du da nutzt? Bzw. deines Autoloaders?

Rolf

[dedlfix]

Tach!

kannst Du mir mal beiläufig verraten, worum es sich bei __ handelt?

Das ist ein valider Identifier, der derzeit nicht von PHP verwendet wird. Generell ist aber empfohlen, mit doppelten Unterstrichen beginnende Namen nicht verwenden, um nicht in Konflikt mit eventuellen zukünftigen PHP-Erweiterungen in Konflikt zu kommen.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Generell ist aber empfohlen, mit doppelten Unterstrichen beginnende Namen nicht verwenden, um nicht in Konflikt mit eventuellen zukünftigen PHP-Erweiterungen in Konflikt zu kommen.

In Anbetracht der Tatsache, dass gettext() als Alias _() hat, würde ich generell von Funktionsnamen dieser Art absehen. Mal abgesehen davon, dass sie nur sehr schwer lesbar sind; _() als Alias für gettext() halte ich bereits für einen Fehler, allerdings ist mir hier wenigstens die Historie bewusst. Bei __() gibt es keine Chance zu verstehen, was das soll.

LG,
CK

[Rolf B]

Hallo dedlfix,

danke für die Bestätigung, dass ich nicht blind war 😀

Aber das heißt jetzt was für die Funktionsfähigkeit dieses Codes? __ ist keine vordefinierte magic method von PHP. Sie ist private. Wer kann sie überhaupt aufrufen? Sinnvoll wäre es, wenn der Autoloader einen Class Initializer aufrufen täte - aber der muss sich dann mühsam ranreflektieren.

Was da genau passiert, hätte ich gern von MB gewusst, der hat's ja gebaut und sicherlich irgendeinen Plan dabei verfolgt.

Rolf

[dedlfix]

Tach!

Aber das heißt jetzt was für die Funktionsfähigkeit dieses Codes?

Das ganze Vorhaben geht nicht auf diese Weise, da muss ich auch nicht den Code dazu analysieren, weil kein Code der Welt zielführend ist. Das Ziel muss neu formuliert werden.

Was da genau passiert, hätte ich gern von MB gewusst, der hat's ja gebaut und sicherlich irgendeinen Plan dabei verfolgt.

Nichts, weil es nicht geht. Müsste einen Syntaxfehler in der const-Zeile geben.

dedlfix.