Diskussion:PHP

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Bitte keine langen Source-Code-Beispiele einfügen. Ein Hello-World sollte reichen.

Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 90 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte.
Archiv-Tabelle Archiv
Zum Archiv
Wie wird ein Archiv angelegt?

Beeinflusst von[Quelltext bearbeiten]

Bitte um Belege, dass PHP von Perl, C/C++, Java beeinflusst wurde. Gerade bei C++ & Java sehe ich keine Gemeinsamkeiten --Sebastian.Dietrich 13:31, 28. Jan. 2015 (CET)

Code in HTML[Quelltext bearbeiten]

Ich vermisse im Abschnitt Kritik ein Grundproblem von PHP. Nämlich, dass PHP-Code innerhalb von HTML- Dokumenten steht. Ich halte diese systemimmanente Fehlerquelle für kritisierenswert. Warum steht da nichts im Artikel? Sollte das Sinn machen, soll ich dann einen Vorschlag zur Ergänzung machen? (Wollte lieber vorher fragen, wäre recht neu hier) Kalle Schmidt (nicht signierter Beitrag von 93.215.34.250 (Diskussion) 22:06, 10. Sep. 2015 (CEST))

Ich verstehe nicht, was daran ein Problem sein soll. Bitte näher erläutern. --Saliwo (Diskussion) 11:26, 4. Dez. 2015 (CET)
Die Formulierung "PHP-Code [steht] innerhalb von HTML-Dokumenten" ist ja wohl auch eher irreführend und beschreibt nur das äußere Erscheinungsbild des PHP-Sourcecodes. Technisch kann man es auch so sehen, dass HTML-Code innerhalb des PHP-Sourcecodes steht und in diesem Sinne einfach ein Bestandteil der PHP-Programmierung darstellt. Inwiefern das zu kritisieren wäre, erschließt sich mir auch nicht. Es ist einfach nur ein sehr pragmatischer Syntax. --92.213.11.156 12:19, 18. Okt. 2016 (CEST)

Änderung im Abschnitt Code-Beispiel[Quelltext bearbeiten]

Im o.g. Abschnitt wurde das abschließende "?>" Tag entfernt, weil eine Webseite behauptet, dass in ein Script, dass nur aus PHP-Code besteht, ein solches nicht enthalten darf. Ich bin der Meinung, dass das imho nicht stimmt. Ein abschließendes Tag stört auch in einem ausschließlich auf PHP basierenden Script nicht. Im Gegenteil: Ich finde es falsch, das abschließende Tag zu entfernen, denn ein Anfänger würde in einem HTML-Element der aus mehreren PHP Abschnitten besteht, auf diese Art und Weise nur Parse-Errors erhalten. Oder was sagt ihr? Wenn nichts gegenteiliges kommt, werde ich in ein paar Tagen das "?>" wieder einfügen. --Saliwo (Diskussion) 11:30, 4. Dez. 2015 (CET)

Dass das abschließende PHP-Tag nicht enthalten sein darf stimmt für den PSR-2-Standard. In meinem eigenen Code lasse ich den schließenden Tag auch weg. Aber das heißt ja nichts. Wo stehen soll, dass Wikipedia diesen Standard in Beispielen verwenden müsste, erschließt sich mir auch nicht, noch dazu, wenn - so wie du das ausführst - es mit abschließendem Tag in diesem Fall sinnvoller ist. Wenn du das korrigierst, kannst du vll. auch direkt die fehlende Einrückung der Codezeile ergänzen. --88.130.88.113 13:09, 9. Dez. 2015 (CET)
Es kommt auf die Definition an. Wann funktioniert ein Script, wann funktioniert es nicht. PSR-2 ist lediglich eine Definition, mehr nicht. PHP an sich, funktioniert selbstverständlich mit einem abschließenden "?>"-Tag. Entsprechend füge ich das nun wieder ein. --Saliwo (Diskussion) 20:04, 9. Dez. 2015 (CET)
Ein Hinweis dazu findet sich im Manual:Der schließende Tag eines PHP-Blocks am Ende einer Datei ist optional, und in einigen Fällen ist das Weglassen hilfreich, wenn Sie include oder require verwenden, so dass ungewollte Whitespaces nicht am Ende einer Datei auftreten und Sie noch im Stande sind, später weitere Header an die Response hinzuzufügen. Es ist ebenfalls praktisch, wenn Sie Output Buffering verwenden und keine ungewollten Whitespaces am Ende eines durch die eingebundenen Dateien erzeugten Parts sehen wollen. Aber aus gewohnheit mache ich die abschließenden "?>"-Tags dennoch. Gruß --Lrwx------ (Diskussion) 23:03, 9. Dez. 2015 (CET)
Ein anderer Aspekt ist auch die Benutzerbarkeit. Je nachdem, wer die Dateien mit dem PHP-Code drin bearbeitet, ist es oft sinnvoll, diese Dateien sehr ...dau-sicher zu machen. Ich seh oft genug Support-Anfragen, in denen der Benutzer Code wie er sollte in einer PHP-Datei eingefügt hat - nur leider hinter dem abschließenden PHP-Tag. Dieses Problem hat man definitiv nicht, wenn so ein Tag gar nicht erst drinsteht. Mit dem hier gewählten Beispiel hat das freilich erstmal nicht viel zu tun. --88.130.123.15 00:12, 10. Dez. 2015 (CET)
Dieses Problem hat man auch nicht, wenn man, sobald man PHP-Code in ein HTML-Dokument einfügt, mit "<?php" einleitet und danach mit "?>" ausleitet. So habe ich es gelernt und funktioniert einfach.--Saliwo (Diskussion) 08:53, 10. Dez. 2015 (CET)
Kein abschließendes ?> ist nicht nur in PSR2 vorgeschrieben (PSR = relevant, weil quasi aller aktueller Code darauf aufbaut, speziell in Verbindung mit Autoloading/Composer), sondern wird von jedem ernsthaften Entwickler so gemacht (solange er nicht vor 10 Jahren Alzheimer bekommen hat), siehe u.a. Drupal, Zend 1 (Zend 3 ist PSR-kompatibel) oder auch offizielle PHP-Projekte. Es gibt nur noch vereinzelte Projekte, die das nicht so handhaben, abe die kann man an einer Hand abzählen und sind bekannt für ihren schlechten Code (bspw. Wordpress) oder dafür, dass sich seit zehn Jahren keiner mehr dafür interessiert (PEAR). Abgesehen davon ist Code und HTML mischen eh noch mal eine ganz andere Sache, die man heute eigentlich auch nicht mehr sieht bzw. tunlichst auch keinem Anfänger zeigen sollte. Meiner Meinung nach sollte man das Beispiel aus dem Artikel verbannen oder zumindest drastisch kürzen und mit Warnung versehen. --21:13, 24. Okt. 2016 (CEST) (ohne Benutzername signierter Beitrag von 185.76.98.8 (Diskussion))

Backronym[Quelltext bearbeiten]

Bevor sich ein Editwar einstellt: Ich finde, dass es sich bei "PHP" um kein Backronym handelt, da, wie die Einleitung bei Backronym schon sagt, es sich dabei um ein Wort handelt. Und PHP ist imho kein Wort, sondern eine Abkürzung. --Saliwo (Diskussion) 20:14, 18. Dez. 2015 (CET)

Sehr schön mal wieder auf jemanden zutreffen der die Netiquette einhalten kann, vielen Dank dafür.
Ich lehne mich mal aus dem Fenster und behaupte du scheinst damit einverstanden zu sein, dass es ein "rekursives Akronym" ist. Ein Akronym ist aber auch ein Wort, wie du hier nachschauen kannst. Außerdem vertraue ich in diesem besonderen Fall dem Englischen Artikel in dem ebenfalls ausdrücklich von "Backronym" die Rede ist und finde es deswegen durchaus angebracht dies hier zu verwenden. MfG --Dnepro.. (schnaken?) 21:00, 18. Dez. 2015 (CET)
Zunächst vielen Dank für dein Lob. Ich bin mir halt nicht sicher, deswegen meinte ich "imho". Programmieren kann ich, aber mit der Deutschen Sprache in all ihren tieferen Facetten hapert es manchmal. Wenn PHP zunächst nur eine Abkürzung ist, aber kein Wort, wird es dann ein Wort, wenn es ein rekursives Akronym ist? Oder dreht man sich da im Kreis? Vielleicht liegt es auch nur daran, dass es sich bei "PHP", "Backronym" und "Akronym" um fremdsprachige Begriffe handelt, die man sowieso niemals zu 100 % korrekt in die deutsche Sprache integrieren kann.--Saliwo (Diskussion) 22:11, 18. Dez. 2015 (CET)
Ja bitte. Genau dafür diese Diskussion. Also sobald ich den Artikel Wort und insbesondere Wort#Charakterisierung richtig verstehe ist "Wort" ein sehr schwer zu definierender Begriff. Aber es ist grundsätzlich eine "Zeichenkette mit Bedeutung", die "durch Trennzeichen (Leerzeichen, Punkte und Kommas) getrennt werden". Insofern hätte ich kein Problem bei "PHP" von einem Wort zu sprechen. Meiner Auffassungen waren Akronyme immer eine Form der Abkürzungen, aber nicht alle Abkürzungen sind Wörter (vergleiche "z.B.") aber alle Akronyme können als Wörter angesehen werden. Nein, diese Wörter sind gut in die deutsche Sprache integrierbar, da sie sprachwissenschaftliche Konzepte behandeln. Backronym ist eine besonderheit des Akronyms, bei der ein Wort wie "PHP" - ("Personal Home Page Tools") nachträglich uminterpretiert wird, PHP ("PHP: Hypertext Preprocessor") und es ist ein rekursives Akronym da es sich selbst als Teil des Akronyms einschließt (siehe auch YAML). MfG --Dnepro.. (schnaken?) 12:14, 19. Dez. 2015 (CET)

Kritik[Quelltext bearbeiten]

Mal stumpf gefragt: Kann der gesamte „Kritik“-Abschnitt nicht raus? Ich halte die Kritikpunkte alle für nicht zwingend. Ich gehe es mal durch: „Ungesteuert gewachsen“: Nicht falsch, aber betrifft längst nicht so viele Funktionen, wie man denken sollte. Meines Erachtens kein sehr starker Kritikpunkt. „Standard-Lib besteht aus Funktionen, obwohl Sprache OOP unterstützt“: Den Punkt halte ich für völlig subjektiv. „Kein Bytecode-Cache vor PHP 5.4“: Kritik ist veraltet und Aspekt war nie von großer Bedeutung. „Schwache Typisierung“: Ebenfalls subjektiv. „Unübliche Vereinigung von Array- und Dictionary-Ansätzen verwirrt Leute“: Finde ich albern. Auf der Basis kann man zig Konzepte in zig Sprachen kritisieren, und nichts davon wäre besonders sinnvoll oder stichhaltig. „Keine explizite Variablendeklaration“: Also, im Ernst… Das ist vielleicht alles eine generelle Kritk an so was wie Script-/Interpreter- vs. Compiler-Sprachen, aber sicher nichts, was bei PHP besonders negativ hervorsticht. Der Zusatz, man solle E_NOTICE aktivieren, um Tippfehler zu finden… Das Level, auf dem sich das bewegt, finde ich aus fachlicher Sicht doch etwas zu seicht. „Register Globals“: Kritik ist veraltet und sachlich auch eher auf der suggestiven Seite einzuordnen, weil das bei sauberer Entwicklung nie ein Problem war. „Ausnahmebehandlung funktioniert nicht zuverlässig“: Erneut subjektiv und sachlich fragwürdig. Hier wird bemängelt, dass PHP nicht durchgängig Exceptions wirft, sondern vielfach einen anderen (älteren) Mechanismus zur Fehleranzeige nutzt. Das ist nicht falsch, lässt sich aber mit „set_error_handler“ und dergleichen recht einfach in den Griff bekommen. --188.118.178.225 13:28, 20. Jun. 2017 (CEST)

Ich habe in dem Absatz mal durchgefegt. --Nolispanmo Disk. Hilfe? 13:56, 20. Jun. 2017 (CEST)
Danke für die Änderungen. Das klingt so in jedem Fall schon mal deutlich gemäßigter. Ich bin natürlich nicht dagegen, Kritik an der Sprache zuzulassen, aber man sollte schon etwas darauf achten, nicht am Ende zum Beispiel unter jedem Eintrag zu einer dynamisch typisierten Scriptsprache als Kritik stehen zu haben, dass sie dynamisch typisiert ist und keine explizite Deklaration von Variablen zulässt und dergleichen. Das kritisiert einfach eher sprachübergreifende Konzepte, die aber durchaus gängig sind. Ob man das nun persönlich mag oder nicht, ist ja gar nicht die Frage. (Ich sehe auch durchaus Probleme damit. Ich sehe aber auch bestimmte Vorteile.) --89.166.209.148 03:26, 28. Jun. 2017 (CEST)