[PHP] INI-Datei Parser

Du hast nicht verstanden, was ich meinte: Bei PHP musst du schreiben: $GLOBALS['globalconfig']['blablub'] = array(…). Es muss wissen, wo die Daten hinmüssen, und das ist nicht unbedingt naheliegend. Oder jetzt schreibt man in PHP $GLOBALS['globalconfig'] = array(…), überschreibt dadurch aber vllt. irgendetwas, mit config-files kann das Programm damit umgehen und es ist völlig unabhängig von der Programmstruktur. Und nein, PHP-Code kannst du nicht so einfach aus einer anderen Programmiersprache heraus benutzen.

Ach komm, wieso sollte ich das in $GLOBALS schreiben? Das ist doch Unfug. Ich schreibe das in einen ganz normalen Array den ich dan genau an der Stelle einbinde wo ich ihn brauche. Das ist NULL Unterschied zu so nem Config-File, das wird dann halt an der Stelle geparst und gibt mir den Array zurück. Das Ergebnis ist 100% identisch.
Und ganz ehrlich, wenn ich sowieso in einer anderen Sprache wieder ein neues Script zum parsen der Config-Datei schreiben muss, weil sie eben keine gängigen Konventionen nutzt, dann kann ich mir auch nen Script schreiben, das mir nen PHP-Array parst. Wenn der vernünftig geschrieben ist ist das genauso easy.

Ähm, nein, wenn du PHP zulässt zur Konfiguration, werden sich mit Sicherheit nicht alle darauf beschränken, eine ganz eingeschränkte Teilmenge von PHP zu benutzen (nur <?, array, Strings, Zahlen und Kommentare z.B.).

Zitat von The User

Ähm, nein, wenn du PHP zulässt zur Konfiguration, werden sich mit Sicherheit nicht alle darauf beschränken, eine ganz eingeschränkte Teilmenge von PHP zu benutzen (nur <?, array, Strings, Zahlen und Kommentare z.B.).

Das ist ein völlig anderer Aspekt als der von dir angesprochene Punkt der Sichtbarkeit (-> $GLOBALS) auf den ich eingegangen bin.
Zu dem Sicherheitsaspekt habe ich schon was geschrieben, nämlich, dass ich in meinen Systemen sowieso niemanden Konfigurationsdateien anlegen lasse, dem ich nicht auch genug vertraue um ihn PHP-Dateien anlegen zu lassen. Userspezifische Style-Definitionen o.ä. die offen für jeden Benutzer sind werden von den Usern über eine entsprechende Eingabemaske im Frontend gemacht und ich entscheide wie ich die dann ablege.

Zitat von Tobse

Genau, den Punkt hatten wir ja schon. Übrigens ist das mit dem PHP Parsen nochmal viel komplexer. Ich wette, die Klasse wäre (natürlich nur fürs array, Strings und Zahlen) mindestens 3mal so groß. Und wenn dann doch jemand anderen PHP Code reinschreibt, dann schlägt der parsrr fehl. Oder wenn jemand ein ($x!=$y ? "a" : "b") reinschreibt? Ein PHP Parser macht hier glaube ich keinen Sinn.

Wenn ich Vorgaben mache wie der PHP-Array notiert sein muss (wie es ja auch bei deinem File der Fall ist) ist das kein großer Unterschied, ich habe dann halt Hochkommata um die Keys und Values, eine Zuweisung per => statt per = und ein Komma am ende der Zeile.
Trotzdem würde ich für Konfig-Dateien die evtl auch in anderen Sprachen verwendet werden müssen ein standardisiertes Format verwenden, und nicht einen PHP-Array oder ein eigenes Format das auf eine bestimmt PHP-Klasse angewiesen ist.

Zitat von Tobse

Richtig. Allerdings müssen die configs, die bei mir in diesem Format vorliegen, nicht in andere sprachen ausser PHP. Darüber habe ich mir auch keine Gedanken gemacht sondern einfach gesagt, SO sollen die aussehen und dann den Parser geschrieben.

Wir drehen uns im Kreis.
Das ist ja auch vollkommen ok wenn bei dir solche Files auch von Leuten kommen denen du nicht gestatten willst PHP-Dateien anzulegen. Bei mir ist das eben nicht der Fall und daher bietet mir die Klasse keinen Mehrwert. Bei meiner ursprünglichen Kritik habe ich mich hauptsächlich an dem Wort ini aufgehangen, weil das ein standardisiertes Format impliziert und somit irreführend ist.

Zitat von SinnlosS

Das ist ein völlig anderer Aspekt als der von dir angesprochene Punkt der Sichtbarkeit (-> $GLOBALS) auf den ich eingegangen bin.

Das bezog sich auch aufs Schreiben eines PHP-Parsers für andere Sprachen. Bezüglich der Sichtbarkeit: Du kommst nicht darum herum, dass das Skript für die Konfiguration mit den Variablen des Programms interferriert, und das ist nicht gut.

Zitat von SinnlosS

Trotzdem würde ich für Konfig-Dateien die evtl auch in anderen Sprachen verwendet werden müssen ein standardisiertes Format verwenden, und nicht einen PHP-Array oder ein eigenes Format das auf eine bestimmt PHP-Klasse angewiesen ist.

Ach komm, nen C++-Parser für .tobse schreib ich in 10 Minuten…

Alles klar ihr habt Recht.
Dann können wir die Diskussion ja abschließen.

Die Perl-Geeks schaffens vmtl. in 4 Minuten und 5 Zeilen.