Ist die Ausgabe 01/2010 "iX Spezial Programmieren heute" lesenswert?

Azgul schrieb:

Was spricht dagegen D für die Spieleprogammierung einzusetzen?

Was spricht für D? Ich würde nicht sagen, dass ich mich wie ein fanboy gegen Alternativen querstelle. Ich lass mich gerne überzeugen. Vielleicht ist D ja doch was ganz tolles. Aber das, was ich da bisher so von gesehen habe -- man sollte doch meinen, die Erfinder haben überzeugende Argumente auf ihren Webseiten -- hat mich kalt gelassen. Es reichte zumindest nicht dafür, dass ich es selbst ausprobieren wollte. Bin ich blind, dass ich die überzeugenen Argumente nicht sehe?

~john schrieb:

Was spricht gegen C++? D ist nicht soviel anders, als das es den Umstieg rechtfertigen würde.

So kommt mir das auch vor. Es sieht wie ein C++/C# Mischmasch mit eingebauten Typen für dynamische/"assoziative" Arrays und Slices.

~john schrieb:

Die großen Probleme von C++ löst es jedenfalls nicht.
Zum Beispiel den Mangel an dynamic dispatching, wodurch es absolut ekelhaft wird Reflection in C++ zu nutzen.

Das -- was immer Du auch damit genau meinst -- soll ein großes Problem sein? Das sehe ich anders. Zumindest war es wohl nicht groß genug, dass Proposals zu dem Thema beim/vom C++ Standardisierungs-Komitee eingereicht wurden. Ich würde behaupten, all das, was sie für C++0x gemacht haben, war wichtiger -- auch der Versuch, direkte Sprachunterstützung für "concepts" einzuführen.

Zeus

Concept sind kein Teil von C++0x mehr. Und andere Teile von C++0x sind in der letzten Treffen(März 2010) auch gefallen.

IMO ist D ein richtig gut Mischung, allerdings ist die Implementierung eher dürftig. Daher denk ich nicht, dass D mehr Akzeptanz bei Entwickler finden wird.

krümelkacker schrieb:

[...] auch der Versuch, direkte Sprachunterstützung für "concepts" einzuführen.

Zeus schrieb:

Concept sind kein Teil von C++0x mehr.

Ich habe nicht das Gegenteil behauptet.

Zeus schrieb:

Und andere Teile von C++0x sind in der letzten Treffen(März 2010) auch gefallen.

Ja und?

nman

SideWinder schrieb:

Hey, der ist ja schwach. Die anderen Fliegen orientieren sich ja tatsächlich daran. Da fällt dir sicher noch etwas besseres ein

Ich verstehe nicht, was Du damit sagen willst. Keine mir bekannte Sprache orientiert sich an PHP.

Falls Dir das Statement oben zu der war: Verbreitung ist kein Indikator für Qualität, egal wie gerne das manche PHP-Fans hätten.

nman schrieb:

Verbreitung ist kein Indikator für Qualität, egal wie gerne das manche PHP-Fans hätten.

Es kommt drauf an, was Qualität für Dich bedeutet. Dein Vergleich mit dem Lieblingsessen der Fliegen könnte bedeuten, dass Dein Qualitätsbegriff ein anderer ist. Vielleicht möchtest Du ihn uns erläutern?

Artchi

Z schrieb:

nman schrieb:

[1] Der Vollständigkeit halber: PHP wurde offensichtlich von einer Horde betrunkener Affen mit verschiedenen schwerwiegenden Lernschwächen geschrieben...

Das scheint keinen zu stören. Schliesslich ist PHP doch ziemlich erfolgreich. :p

Aber nur weil jeder Billig-Webhoster in seinem Angebot PHP drin hat...
*
"Ehm, ich will jetzt mal ein Gästebuch für meine Homepage proggen. Ah, da schau her! Für 99 cent ist da ein Angebot, auf dem ich dynamische Seiten mittels PHP frickeln kann. Cool, wird mein Gästebuch doch noch was!".*

PHP ist nicht erfolgreich, weil es so toll ist, sondern weil die User das Zeug vorgesetzt bekommen.

Artchi

Ich finde D eigentlich als C++-Alternative theoretisch interessant. Aber halt nur theoretisch und nicht praktisch interessant. D wird es schwierig haben, weil es nicht offen und vorallem auf zu wenig Plattformen verfügbar ist.

C++ hat seine Haken und Ösen, aber ich kann C++ auf jeder verdammten Plattform programmieren. Egal ob auf Spielekonsolen, Mobile-Telefon oder exotischen Systemen wie den Amiga oder RISC OS. Gerade auf diesen letzt genannten Systemen ist C und C++ die letzt verbliebene ernsthafte Sprache. Aber das zeigt sehr schön die Verbreitung und das unermüdlich Durchhaltevermögen von C und C++!

Wer kennt REBOL? Das ist eine Sprache die auch theoretisch sehr interessant ist. Aber sie ist nicht offen und auch nur auf (zu) wenig Plattformen verfügbar. Also irgendwie ist das doch alles nicht sehr motivierend, außer das man da "reinschnuppert".

Wenn ich C++ lerne, kann ich mein Wissen auf jeder Plattform anwenden. Wenn ich D lerne, bin ich auf zwei oder drei Plattformen beschränkt. Ich kann nicht mal einfachste Algorithmen von Plattform A auf B portieren, weil auf B der D-Compiler fehlt.

Andere Sprachen, wie Lua und Python sind sogar auf RISC OS und Amiga verfügbar. Sie sind offen, und wurden portiert. Wenn ich Lua auf dem PC kann, kann ich das auch auf exotischen Systemen anwenden.

nman

Qualitätsmanager schrieb:

Es kommt drauf an, was Qualität für Dich bedeutet. Dein Vergleich mit dem Lieblingsessen der Fliegen könnte bedeuten, dass Dein Qualitätsbegriff ein anderer ist. Vielleicht möchtest Du ihn uns erläutern?

Eigentlich nicht. Ich kenne keine sprachinteressierte Person, die PHP für eine gut entworfene Programmiersprache hält und das Internet ist voll mit Gründen, warum PHP furchtbar ist.

PHP ist leicht oberflächlich lernbar und leicht deploybar. Das sind natürlich nach einer gewissen Metrik Qualitäten, die auf die Verbreitung eine spürbare Auswirkung haben. Allerdings ziehe ich gerne nicht nur derartige Kriterien heran, um die Qualität einer Sprache zu beurteilen. Dabei möchte ich es auch schon wieder belassen, wer große Lust hat, über das Thema zu sprechen, möge mal in #c++ vorbeischaun und mich darauf anquatschen, ich schreibe hier einfach sehr ungerne über derartige Themen.

Artchi schrieb:

Z schrieb:

nman schrieb:

[1] Der Vollständigkeit halber: PHP wurde offensichtlich von einer Horde betrunkener Affen mit verschiedenen schwerwiegenden Lernschwächen geschrieben...

Das scheint keinen zu stören. Schliesslich ist PHP doch ziemlich erfolgreich. :p

Aber nur weil jeder Billig-Webhoster in seinem Angebot PHP drin hat...
*
"Ehm, ich will jetzt mal ein Gästebuch für meine Homepage proggen. Ah, da schau her! Für 99 cent ist da ein Angebot, auf dem ich dynamische Seiten mittels PHP frickeln kann. Cool, wird mein Gästebuch doch noch was!".*

PHP ist nicht erfolgreich, weil es so toll ist, sondern weil die User das Zeug vorgesetzt bekommen.

Ich denke, PHP ist so erfolgreich, weil auch Leute ganz schnell damit etwas hinbekommen, die vorher nie programmiert haben. Das halte ich für eine gute Sache. PHP erhebt nicht den Anspruch, C++ zu ersetzen. Beide Sprachen haben ihre Anwendungsgebiete.

Ich habe mal einen zweiwöchigen PHP-Kurs mitgemacht. Vorher war ich auch voller Vorurteile, gegen alles was interpretiert wird und nicht direkt auf dem Prozessor läuft. Aber hinterher war ich positiv überrascht, wie einfach und schnell man PHP verwenden kann. Das einzige, was mir immer noch an PHP missfällt, sind die Dollarzeichen vor den Variablen.

Shade Of Mine

Artchi schrieb:

PHP ist nicht erfolgreich, weil es so toll ist, sondern weil die User das Zeug vorgesetzt bekommen.

PHP hat das richtige Konzept mit der falschen Sprache. Aber das Konzept ist einfach genial.

Weg von dem CGI Blödsinn den es vorher gab (Scripte in dem cgi-bin ordner) und den Code direkt in den HTML Seiten. dazu das geniale Konzept eines include() und fertig.

Dass dann der rest furchtbar ist, nimmt man dann halt in kauf. Aber integrier mal in eine webseite interaktive teile mit perl oder python. ist ne katastrophe.

diese richtigen webanwendungen kamen ja viel später. und auch da steht php nicht so schlecht da, da du einfach tools für alles hast. cpan-light quasi :p

das sind sachen die man nicht vergessen darf. trotz schlechter sprache ist eben die plattform genial. im prinzip gibts nur 3 sachen die an php schlecht sind:
die sprache
die library
der interpreter

der rest ist super

nman

Z schrieb:

Ich habe mal einen zweiwöchigen PHP-Kurs mitgemacht. Vorher war ich auch voller Vorurteile, gegen alles was interpretiert wird und nicht direkt auf dem Prozessor läuft.

Uh, "nicht direkt auf dem Prozessor"? Egal.

Ich verwende zahlreiche Sprachen gerne, die nicht in Maschinencode kompiliert werden, habe da weder Vorurteile, noch Berührungsängste. Ich finde auch Sprachen gut, die anfängerfreundlich sind. Das sind nicht die Gründe, aus denen PHP Mist ist.

Werdet doch mal konkret. Was findet ihr an PHP so schlecht, das es insgesamt zu einer schlechten Programmiersprache macht?

nman

Bemühe doch bitte mal Google. Das Internet ist voll mit Erläuterungen, warum PHP Mist ist.

http://plasmasturm.org/log/393/
http://www.steike.com/code/php-must-die/
http://maurus.net/resources/programming-languages/php/
http://webonastick.com/php.html
http://www.bitstorm.org/edwin/en/php/
…

rüdiger

An PHP ist einfach so vieles falsch. Sicher fing es als praktischer hack an. Man wollte etwas, was einfacher als C war und was man einfach auf einen Server hochladen konnte ohne damit alle anderen User abschießen zu können (damals gab es Virtualisierung in dem Maß noch nicht und Webspace hieß ja wirklich, dass man ein ~/user/webroot auf irgend einem Unixrechner hatte). Man wollte etwas was verständlicher als Perl war.

Aber die Entwickler von PHP waren halt keine Sprachdesigner. Und es ist immer blöd, wenn wenig erfahrene Leute etwas in dem Bereich machen. Also haben die halt alles aus C, C++, Perl, Shellskript und anderen Sprachen zusammen gewürfelt, was sie finden konnten. Daher hat man diesen hässlich inkonsistenten Mix als Grundsprache. Das wurde natürlich noch schlimmer, weil man immer mehr Features dazugewürfelt hat. Vom Sprachdesign ist PHP also schon einmal unten durch.

Die Bibliotheken sind ein wilder Mix: Alles im globalen Namespace und keine einheitliche Namenskonvention. Wie die Sprache an sich, einfach dazu gewürfelt, wenn man es mal gerade gebraucht hat. (Beispiel: Es gibt ein mysql_escape_string aber die API ist fehlerhaft. Also führt man ein mysql_real_escape_string ein und behält die alte Funktion bei...)

Der Interpreter ist extrem mies. Die Firma hinter PHP lebt ja nicht umsonst davon, dass man einen Beschleuniger dafür verkauft. Aber wenn man sich anschaut, mit welcher "Kompetenz" dieser misst entwickelt wird...

Was gibt "print 08;" in PHP aus? 0! Weil die Entwickler keine Ahnung von Octalzahlen und der richtigen Verwendung von man: strtol haben. http://www.steike.com/code/php-must-die/

Schaut euch an, wie die Integeroverflows versuchen zu fixen: http://use.perl.org/~Aristotle/journal/33448 *aaaah* m(

Solchen Code wollt ihr auf euren Servern laufen lassen? Den Leuten wollt ihr die Sicherheit eurer Firma anvertrauen?

PHP ist ja auch nur oberflächlich einfach. Sicher kann damit auch jemand ohne größere Programmiererfahrung eine Webseite hinbekommen. Aber das reicht eben noch nicht. Man muss sich ja nur die ganzen Webseiten mit SQL Injection oder XSS Problemen anschauen... Wieviele Webseiten wurden schon gehackt, weil die einfach von einem Codemonkey mit PHP zusammengefrickelt wurde? PHP macht es vorallem leicht unsichere Webseiten zu schreiben.

PHP ist die schlechteste Programmiersprache, mit der schlechtesten Library und der schlimmsten Implementierung und das alles von Leuten geschrieben, die man besser nicht einmal ein "Hello World" programmieren lässt.

rüdiger

nman schrieb:

Bemühe doch bitte mal Google. Das Internet ist voll mit Erläuterungen, warum PHP Mist ist.

http://plasmasturm.org/log/393/
http://www.steike.com/code/php-must-die/
http://maurus.net/resources/programming-languages/php/
http://webonastick.com/php.html
http://www.bitstorm.org/edwin/en/php/
…

Nette Sammlung.

Christoph

Z schrieb:

Werdet doch mal konkret. Was findet ihr an PHP so schlecht, das es insgesamt zu einer schlechten Programmiersprache macht?

Ich erlaube mir, Auszüge aus einem IRC-Channel (von verschiedenen Tagen in diesem Jahr) zu posten. Die Namen habe ich anonymisiert, weil die Gesprächspartner unwichtig ist. Alle Gesprächsteilnehmer sind Leute, die das Forum regelmäßig und seit langer Zeit besuchen.

Man sieht deutlich den Frust, den die Sprache auslöst.

<AAAA> auf Slashdot hat letztens jemand einen anderen Auszug aus der
        PHP-Doku gepostet.
<AAAA> wie array-Indizes behandelt werden.
<AAAA> assoziative Arrays (d.h. string-indizes) und normale Arrays
        (int-Indizes) sind erstmal von vornherein derselbe Datentyp.
<AAAA> $a['8'] ist dasselbe wie $a[8]
<AAAA> $a['08'] ist nicht dasselbe wie $a[8]
<AAAA> wenn der Array-Index eine Fließkommazahl ist, wird diese
        stillschweigend (ohne Warnung!) konvertiert in einen int.

Das habe ich übrigens getestet: Es stimmt.

<AAAA> BBBB: hatte ich erwähnt, dass PHP furchtbar und ganz grässlich ist?
<AAAA> BBBB: typische Kommentare in der PHP-Doku sind "ach, übrigens,
        die Funktion macht eigentlich etwas völlig anderes als oben in
        der Doku steht, und zwar wie folgt: ..."
<BBBB> AAAA: das passt dann wenigstens zum verhalten der meisten in
        php geschriebenen software.
<AAAA> BBBB: ja, leider.
<AAAA> BBBB: ich hatte letztens das Vergnügen, die Funktion
        "escapeshellarg" in PHP zu sehen.
<AAAA> BBBB: http://php.net/manual/en/function.escapeshellarg.php
<AAAA> BBBB: die Doku klingt so, als wäre diese Funktion höchstens 5
        Zeilen lang
<AAAA> BBBB: man kann nun wirklich nicht viel falsch machen bei so
        einer Funktion, sollte man meinen.
<AAAA> eigentlich genügen zwei Zeilen: 1) ersetze ' durch '"'"' 2)
        return "'" + $result + "'";
<AAAA> quoting mit single-quotes für die Shell
<BBBB> und? wie haben die php-leute es geschafft?
<AAAA> BBBB: naja... das ist haarsträubend.
<AAAA> BBBB: diese Funktion wertet irgendeine Umgebungsvariable aus
        (vermutlich $LC_ALL). Wohlgemerkt, *nicht* die globale
        Variable von mb_internal_encoding(), die von anderen
        String-Funktionen verwendet wird.
<AAAA> BBBB: falls in dem Argument ein Zeichen vorkommt, das nicht
        repräsentierbar ist in diesem bestimmten Encoding, dann bricht
        die Funktion an dieser Stelle ab.
<AAAA> und liefert einen halbfertigen String zurück.
<AAAA> immerhin gequotet.
<BBBB> uff. debugging-schreikrampf ahoi. :)
<AAAA> oh ja.
<AAAA> vor allem, wenn mb_internal_encoding() auf "utf-8" steht und
        die Umgebungsvariable "LANG" auf en_US.UTF-8
<BBBB> naja, ich habe vor ein paar wochen ein interview mit dem
        erfinder von php gelesen, seitdem wundert mich das alles nicht
        mehr.
<AAAA> laut einem Kommentar in der Doku soll man LC_ALL setzen für den
        Apache-Prozess
<AAAA> um das zu fixen
<BBBB> aua. schmerzen.
<AAAA> so ein Fix ist super.
<AAAA> Wartbarkeit = 0
<AAAA> und beim nächsten Serverumzug bricht alles auseinander

Es kann natürlich sein, dass AAAA hier einen Fehler gemacht hat: mb_internal_encoding() und die Umgebungsvariable LANG sind richtig gesetzt, aber vielleicht fehlt etwas anderes. In jedem Fall gilt, dass die PHP-Doku mehr als unzureichend ist, wenn so ein Versagen einer PHP-Funktion undokumentiert ist.

<AAAA> ähnlich schlimm ist übrigens mb_encode_mimeheader
<AAAA> du weißt ja sicher grob, wie Umlaute in E-Mail-Headern kodiert
        werden
<AAAA> (das ist auch schon furchtbar, unabhängig von PHP, aber egal)
<AAAA> mb_encode_mimeheader nimmt zwei wichtige Parameter: 1) "the
        string being encoded" und 2) charset
<AAAA> Dokumentation für den zweiten Parameter: charset specifies the
        name of the character set in which str is represented in. The
        default value is determined by the current NLS setting
        (mbstring.language). mb_internal_encoding() should be set to
        same encoding.
<AAAA> da frag ich mich sofort: Wenn das sowieso dasselbe sein soll
        wie mb_internal_encoding(), *warum* muss ich den übergeben?
<BBBB> wtf?
<AAAA> naja, interessant ist das Verhalten, wenn das nicht dasselbe
        ist. Das ist offensichtlich undokumentiert, stört
        mb_encode_mimeheader aber wenig.
<AAAA> die Doku ist sowieso völlig daneben
<AAAA> der zweite Parameter gibt *nicht* das encoding an, in dem str
        (der erste Parameter) repräsentiert ist.
<AAAA> es gibt das encoding an, das im E-Mail-Header verwendet soll,
        also quasi das Ziel-Encoding.
<AAAA> ist ja auch fast dasselbe wie das Quell-Encoding, so ein Detail
        kann schonmal unter den Tisch fallen.
<AAAA> naja, das Quell-Encoding holt sich die Funktion dann aber
        woher?
<AAAA> natürlich aus mb_internal_encoding()
<AAAA> und wenn das nicht übereinstimmt mit dem zweiten Parameter,
        dann kodiert die Funktion den String um.
<AAAA> das, was normalerweise Bibliotheken wie iconv machen würden.
<AAAA> diese Schmerzen.
<AAAA> achso, das umkodieren sieht auch so aus, das nicht
        repräsentierbare Zeichen einfach übersprungen werden, ohne
        Warnung, ohne Fehlermeldung.
<AAAA> aber das wundert bestimmt niemanden mehr.
<BBBB> naja, ich habe vor kurzem mit einem bekannten gesprochen, der
        utf-8-taugliche software in php schreiben muss. ich bemitleide
        den armen kerl.
<AAAA> oh ja.
<AAAA> das ist ein einziger Krampf.
<AAAA> achso, mb_encode_mimeheader hat laut einiger Kommentare einige
        ziemlich übliche Bugs gehabt, was escaping und encoding
        etc. angeht.
<AAAA> keine Ahnung, wie viele davon noch aktuell sind.
<AAAA> besonders cool finde ich ich das Beispiel bei
        mb_encode_mimeheader() in der Doku
<AAAA> $name = ""; // kanji
<AAAA> nur steht da halt kein Kanji :)
<AAAA> als ob das Framework, in dem die Doku geschrieben wurde, nicht
        unicode-safe ist
<BBBB> pff, wenn das locale vom webserver von php.net auch nicht
        richtig gesetzt ist...

<AAAA> BBBB: kennst du die Funktion utf8_decode()? :)
<AAAA> BBBB: die zeigt deutlich den Weitblick der PHP-Entwickler.
<BBBB> AAAA: nein, mein php-wissen ist irgendwann um 2003 sowas
        stehengeblieben. damals war ich ueberzeugt, dass die sprache
        nicht reparierbar ist.
<AAAA> BBBB: utf8_decode macht folgendes.
<AAAA> BBBB: "This function decodes $data, assumed to be UTF-8
        encoded, to ISO-8859-1."
<AAAA> praktisch, wenn man in Westeuropa lebt und kein Euro-Symbol
        braucht.
<BBBB> oh, also nicht 8859-15, sondern wirklich 8859-1. :)
<BBBB> wenigstens passt die doku. :)
<AAAA> BBBB: kA
<AAAA> BBBB: würde mich ehrlich gesagt auch nicht wundern, wenn die
        Funktion in Wirklichkeit nach -15 konvertiert.
<AAAA> BBBB: aber dieser Weitblick ist doch unglaublich.
<BBBB> AAAA: und das euro-zeichen woanders kaputtgeht? :)
<BBBB> AAAA: wie gesagt, wundert mich alles lange nicht mehr.

<AAAA> BBBB: wo ich vor Jahren mal drauf gestoßen bin:
        http://pear.php.net/bugs/bug.php?id=11238
<AAAA> BBBB: inzwischen (seit knapp 2 Monaten) ist es "fixed in SVN"
<AAAA> nach 2,5 Jahren.
<AAAA> BBBB: dieser Bug sagt im Endeffekt: Empfänger wie "Herr Müller
        <mueller@example.com>" sind in PEAR::mail broken.
<AAAA> BBBB: nicht-ascii-Zeichen im Empfänger-Namen sind broken.
<AAAA> das ist ja auch total abwegig, dass man sowas brauchen würde.
<BBBB> und das war eine regression offensichtlich?
<BBBB> laut bugreport zumindestens.
<AAAA> nicht nur Empfänger-Name, sondern auch Absender, natürlich. Das
        betraf alle Header, die E-Mail-Adressen enthalten.
<AAAA> BBBB: hm, stimmt.
<AAAA> BBBB: dann ist es noch weniger entschuldbar, dass der Bug 2,5
        Jahre offen war.
<CCCC> lolol

Mir ist klar, dass in den Rants oben ein wenig übertrieben wird. Die Fakten sollten, soweit ich sie geprüft habe, aber alle korrekt sein.
Das sind jedenfalls alles sehr konkrete Fälle, wo PHP einfach kaputt, unzureichend dokumentiert oder beides ist.

SideWinder

Das mit dem Euro-Zeichen hat mir auch sehr viel Spaß gemacht: Hat mir auch 6,5h Entwicklungszeit gekostet

MfG SideWinder

Rhombicosidodecahedron

@Christoph
*Popcorn hol* Woooww, Coool, gibt es dazu eine Fortsetzung? Scheint interessant zu sein

~kleine Offtopic Frage:~

Sind wir überhaupt noch On-Topic????

^oder sind wir in einen zugegebenermaßen interessanten und begründeten PHP-Bashing / Blamewar abgeglitten?^

Christoph

Rhombicosidodecahedron schrieb:

Woooww, Coool, gibt es dazu eine Fortsetzung? Scheint interessant zu sein

Das geht ganz einfach: http://www.php.net/

Dort steht auf der Startseite z.B.: "PHP 5.3.2 Released!". Etwas weiter unten steht:
# Fixed bug #50847 (strip_tags() removes all tags greater then 1023 bytes long).

Ok, eine willkürliche 1023-Bytes-Grenze ist schonmal verdächtig. Mal schauen, was strip_tags eigentlich macht: http://www.php.net/manual/en/function.strip-tags.php

Offizielle Doku schrieb:

This function tries to return a string with all NUL bytes, HTML and PHP tags stripped from a given str .

Bis hierher klingt es vernünftig. Wobei, "tries"? Aber egal, vielleicht gibt die Funktion einfach ihr bestes.

Offizielle Doku schrieb:

It uses the same tag stripping state machine as the fgetss() function.

Bitte was, state machine? Regexp nenn ich normalerweise nicht "state machine", obwohl es das theoretisch sein mag. Also ist die Funktion vielleicht gar kein Einzeiler, der nur eine regexp anwendet?

Das Rätsel lüftet sich, wenn man zum zweiten Parameter kommt:

Offizielle Doku schrieb:

allowable_tags You can use the optional second parameter to specify tags which should not be stripped.

Ok, in diesem Parameter können wir also Tags spezifizieren, die nicht entfernt werden sollen. Spezifizieren... nur wie? Laut Signatur ist der zweite Parameter ein string. Wie sollen wir dort Tags spezifizieren ohne Angabe des erwarteten Formats? Zum Glück gibt es ein Beispiel:
strip_tags($text, '<a>'); // Allow and <a>
Wenn $text der String 'Test paragraph. <a href="#fragment">Other text</a>' ist, dann wird dort nichts entfernt, weil und <a> erlaubt sind. Dafür ist der zweite Parameter also da. Warum der zweite Parameter nicht einfach ein Array von Strings ist, bleibt weiterhin ein Rätsel.

Mal überlegen, wofür man diese Funktion vermutlich einsetzen würde, wenn man sie zum ersten Mal sieht und nicht weiß, was PHP sonst so hat. Tags strippen, aber bestimmte Tags erlauben. Klingt nach einer billigen Variante, um vom User eingebene Texte zu validieren. Leider ist strip_tags dafür vollkommen unbrauchbar, wie die dicke rote Warnung weiter unten schreibt:

Offizielle Doku schrieb:

Warning This function does not modify any attributes on the tags that you allow using allowable_tags, including the style and onmouseover attributes that a mischievous user may abuse when posting text that will be shown to other users.

Mit anderen Worten: Wenn wir den zweiten Parameter weglassen und einfach alle Tags strippen, dann kann man vielleicht (vielleicht) damit Input validieren. Wenn man den zweiten Parameter nutzt, ist es völlig vorbei, weil man in einem onmouseover-Attribut so ziemlich alles anstellen kann.

Das Problem ist: Die Existenz des zweiten Parameters verkompliziert die ganze Implementierung von strip_tags um Größenordnungen. Würde strip_tags einfach das machen, was der Name sagt, würde es keinen zweiten Parameter geben und die Implementierung wäre relativ überschaubar, hätte also weniger Bugs.

Das Verhalten von strip_tags bei nicht-wohlgeformten HTML ist übrigens undokumentiert, aber das war eh zu erwarten. Das einzige, was die Doku dazu sagt, ist "das kann schiefgehen".

Wenn das alles nicht wirklich in der offiziellen Doku stehen würde, ich würde denken, da hätte jemand eine Satire-Seite aufgezogen. So traurig ist das.

Wenn irgendjemand nochmal bezweifelt, dass PHP eine schlechte Sprache ist: Einfach auf die offizielle Doku verweisen.

p.s.: Easteregg.

SideWinder

BTW: Bald wird PHP6 ja alles richten...

MfG SideWinder

Ist die Ausgabe 01/2010 &quot;iX Spezial Programmieren heute&quot; lesenswert?

Sind wir überhaupt noch On-Topic????

Ist die Ausgabe 01/2010 "iX Spezial Programmieren heute" lesenswert?