saftmeister
Nutze den Saft!
Ist doch unfassbar, wie lange es dauert, bis sich die Entwickler einer Software mal bewegen. Und dann nach Krücken suchen, anstatt sich auf den Hosenboden zu setzen und Hausaufgaben zu machen. ;-)
✔ Neues in PHP 7
- Themenstarter saftmeister
- Beginndatum
Ähm, war das nicht klar das die MySQL Erweiterung mal rausfliegt?
Also ich hab nur drauf gewartet.
Also ich hab nur drauf gewartet.
saftmeister
Nutze den Saft!
Es ist ja nicht so, dass mysqli sehr nah an der mysql-Erweiterung dran ist. Sich alle MySQL-Funktionen in der IDE suchen zu lassen und dann durch mysqli-Aufrufe auszutauschen ist ja nicht wirklich ein Problem.
Bei meinem Hoster läuft PHP7 seit dem 4.12.
sheel
I love Asm
Ja, das war seit vielen Jahren schon klar, aber trotzdem gibts unzählige Leute die noch immer
neuen Code damit geschrieben haben (statt gleich die zukunftssichere Variante zu nehmen)
In den meisten Fällen nur, weil man daran schon gewöhnt war oder grad erst beim PHP-Lernen
ist und dem erstbesten alten Tutorial im Netz zu viel geglaubt hat.
mermshaus
Erfahrenes Mitglied
saftmeister hat gesagt.:
Ja, bei geringerem Umfang des Codes und/oder wenigen Aufrufen ist eine Umstellung recht fix gemacht. Schwieriger wird es bei großen Projekten oder auch bei Fremdsoftware, die vom Anbieter nicht oder nicht mehr aktualisiert wird.
Generell wird die – wahrscheinliche – anhaltende Nutzung der mysql-Erweiterung in aktuell installierten Webanwendungen wohl auch oft daran hängen, dass etliche Kunden selbst keine Entwickler sind und deshalb überhaupt keinen Bezug dazu haben, welche Features etwa einer Sprache wann als deprecated markiert oder sogar entfernt werden. Sie haben die Software einmal eingekauft oder schreiben lassen und seitdem verrichtet sie ihren Dienst und das Thema ist abgehakt. Software oder EDV-Systeme, die völlig ohne halbwegs regelmäßige Wartung auskommen, sind natürlich mehr oder weniger eine Illusion, aber ich finde die skizzierte Betrachtungsweise dennoch eigentlich gar nicht so verkehrt und würde mir wünschen, dass wir als Entwickler oder als Branche tatsächlich mehr so nachhaltig arbeiten würden, dass die Software auch in vielen Jahren noch lauffähig ist. Und das idealerweise dazu auch noch fehlerfrei.
saftmeister
Nutze den Saft!
Das ist so unfassbar: https://github.com/dshafik/php7-mysql-shim/blob/master/lib/mysql.php
bofh1337
Erfahrenes Mitglied
ENDLICH!
(Short-)Tags wurden entfernt. Die Erkennung für die Tags <% und <script language="php"> wurde entfernt.
HAHAHAAHA, unzählige Pfuscher werden an meine Worte von 2014 denken xD Hoffentlich ist dann auch sowas wie "<?=" als Tag ungültig
mermshaus
Erfahrenes Mitglied
Short-Tags im Sinne dieser Direktive bleiben von dem RFC explizit unberührt.
Entfernt wurden mit Version 7 die ASP-ähnlichen Tags (<% … %>) und die HTML-script-Tags (<script language="php">…</script>).
<?php und <?= sind – Stand jetzt (seit PHP 5.4.0) – immer verfügbar. Die Nutzung von <?= ist unproblematisch, und es deutet meines Wissens auch nichts darauf hin, dass sich daran was ändern könnte.
<? hängt von der oben verlinkten Konfigurationseinstellung ab. Deshalb ist tendenziell eher von der Nutzung abzuraten, um diese Abhängigkeit zu umgehen. Der Gewinn von <? gegenüber <?php ist zudem meines Erachtens nicht gewaltig.
Edit:
Das Problem mit <? ist, dass es auch in "<?xml" auftritt, was zum Beispiel in HTML-Dateien mit XML-Prolog (also „echten“ XHTML-Dateien sozusagen) öfter mal fälschlicherweise den PHP-Parser angeworfen hat.
Das Syntax-Highlighting des Forums demonstriert das freundlicherweise:
(Also, das wäre der Inhalt einer index.php-Datei, wie er im Editor steht, also vor dem Ausführen von PHP.)
Das hier war früher, als man manchmal noch XML-Prologe nutzte, ein übliches Pattern, um das zu umgehen:
(So Pi mal Daumen jedenfalls. Ich kriege es nicht mehr genau auf die Reihe, weil es länger her ist.)
Und beim „händischen“ Erstellen von tatsächlichen XML-Dateien mit PHP besteht das Problem natürlich noch immer.
Entfernt wurden mit Version 7 die ASP-ähnlichen Tags (<% … %>) und die HTML-script-Tags (<script language="php">…</script>).
<?php und <?= sind – Stand jetzt (seit PHP 5.4.0) – immer verfügbar. Die Nutzung von <?= ist unproblematisch, und es deutet meines Wissens auch nichts darauf hin, dass sich daran was ändern könnte.
<? hängt von der oben verlinkten Konfigurationseinstellung ab. Deshalb ist tendenziell eher von der Nutzung abzuraten, um diese Abhängigkeit zu umgehen. Der Gewinn von <? gegenüber <?php ist zudem meines Erachtens nicht gewaltig.
Edit:
Das Problem mit <? ist, dass es auch in "<?xml" auftritt, was zum Beispiel in HTML-Dateien mit XML-Prolog (also „echten“ XHTML-Dateien sozusagen) öfter mal fälschlicherweise den PHP-Parser angeworfen hat.
Das Syntax-Highlighting des Forums demonstriert das freundlicherweise:
(Also, das wäre der Inhalt einer index.php-Datei, wie er im Editor steht, also vor dem Ausführen von PHP.)
PHP:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">Das hier war früher, als man manchmal noch XML-Prologe nutzte, ein übliches Pattern, um das zu umgehen:
(So Pi mal Daumen jedenfalls. Ich kriege es nicht mehr genau auf die Reihe, weil es länger her ist.)
PHP:
<?php echo '<?xml version="1.0" encoding="utf-8"?>'; ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">Und beim „händischen“ Erstellen von tatsächlichen XML-Dateien mit PHP besteht das Problem natürlich noch immer.
Zuletzt bearbeitet:
