Mailinglisten-Archive |
Sascha Schumann wrote: > > > Aber ein printf() benötige ich jedoch ungleich öfter als ein > > fprintf(), entsprechend macht es Sinn dieses einzubauen. > > Bitte lies das nochmal durch. Bei dieser Argumentationslinie > kommst du hinterher auf "PHP ist meine Sprache". :) > > Wir verfahren nach dem Grundsatz: Du sollst nichts in C > schreiben, was in PHP implementierbar ist. Ob man jetzt fünf > Buchstaben mehr oder weniger eingeben muß, ist irrelevant. Ok, laß uns mal durch das PHP gehen und die Hälfte wegwerfen ;-). PHP besteht bereits zu weiten Teilen aus Dingen, die ohne Schwierigkeiten in PHP selbst implementiert werden können. Schau doch nur mal auf die Menge der String- und Arrayfunktionen. Praktisch alles kann man auch in PHP schreiben. Dennoch ist es vorhanden, weil es performanter ist (ja Du hast darauf im Falle von fprintf() bereits Hartmut geantwortet). Mehr als die Existenz der Funktion stört mich das die API uneinheitlich ist, hierauf sollte verstärkt geachtet werden. Uneinheitlichkeit ist etwas was PHP wirklich schadet. Hartmuts Argument eine starke Anlehnung an C zu vollziehen, kann ich durchaus nachvollziehen. Erfahrenen Programmieren den Einstieg zu erleichtern, ist eine wichtige Richtlinie für die weitere Ausgestaltung von PHP. fprintf() macht den Kohl auch nicht mehr fett und würde durchaus Sinn machen im Vergleich zu strstr()/strrstr()/strchr()/strrchr(). Wer sich daran stört, kann es ja auskommentieren, so wie ich auch nicht alle Module in mein PHP einbinden muß. Und sed? Ja es gibt Postscript-, awk- und diverse andere Webserver. Warum machen wir eigentlich keine Webprogrammierung in Assembler mit einem Tool das keine Makros versteht... Ich höre ja schon auf. Unterm Strich bleibe ich dabei: die Implementation von fprintf() wäre durchaus sinnvoll. Ulf -- Ulf Wendel NetUSE AG, Siemenswall, 24107 Kiel, Germany Fon: +49 431 386435 00 -- Fax: +49 431 386435 99
php::bar PHP Wiki - Listenarchive