# PHP 7 erschienen!



## Ap0ll0XT (4. Dezember 2015)

Seit gestern ist die neue Version der beliebten Web-Skriptsprache PHP draußen. Die Version 7 bietet allerhand Neuerungen sowie das entfernen vieler alter Features.

*Das ist neu:*
*Konstanten mit Ausdruck anstatt Funktionsaufruf deklarieren*

```
const TEST = 1;
const HALLO = 1 + TEST;

echo Str(HALLO); // Gibt "2" aus
```
*Vorher*

```
Define("TEST", 1);
Define("HALLO",1+TEST);

echo Str(HALLO); // Gibt "2" aus
```

*Variable Parameteranzahl bei Funktionen ohne func_get_args()*

```
function test(...$params)
```
Parameter werden in das Array "$params"geschrieben.

*Neuer Potenz-Operator*

```
$test = 2 ** 3;

echo Str($test); // ergibt "8"
```

*use function und use constants für Namespaces*

```
namespace Name\Space {
    const FOO = 42;
    function f() { echo __FUNCTION__."\n"; }
}

namespace {
    use const Name\Space\FOO;
    use function Name\Space\f;

    echo FOO."\n";
    f();
}
```

Ebenfalls dazu sind strikte Datentypen und weitere Operatoren. Alle Änderungen: PHP: PHP 7 ChangeLog


----------



## Zeiss (4. Dezember 2015)

Manche Änderungen sind einfach nur


----------



## Ap0ll0XT (4. Dezember 2015)

Zeiss schrieb:


> Manche Änderungen sind einfach nur


Anstatt immer nur das negative Fallobst aus dem riesen Salat zu picken versuch auch mal, die Rosinen zu erwischen. Da sind so einige gute Änderungen bei.


----------



## lowskill (7. Dezember 2015)

Bevor ich mir Rosinen aus dem Kompost picken muss, wähle ich lieber gleich eine andere Sprache.


----------



## xActionx (7. Dezember 2015)

These Top 10 Programming Languages Have Most Vulnerable Apps on the Internet - The Hacker News

PHP ist und bleibt ein Scherbenhaufen...


----------



## RicoBrassers (7. Dezember 2015)

xActionx schrieb:


> These Top 10 Programming Languages Have Most Vulnerable Apps on the Internet - The Hacker News
> 
> PHP ist und bleibt ein Scherbenhaufen...



Liegt aber eher daran, dass die Programmierer der Apps einfach die Lücken nicht geschlossen haben.
Den Großteil aller SQL-Injections kann man in PHP schon mit einem einfachen

```
$db = new mysqli(...);

$db->real_escape_string($string)
```
lösen. Wer daran nicht denkt, einfach, weil ihm solche Lücken unbekannt sind (z.B. weil der Programmierer damit noch nie konfrontiert wurde), ist selber Schuld. Das hat dann nichts mit der Sprache PHP an sich zu tun. 

Ich finde es schön, dass endlich wieder eine neue PHP-Version draußen ist. Auch wenn ich mittlerweile hauptsächlich mit NodeJS arbeite - "altbackene" Foren- und CM-Systeme laufen immer noch in PHP und "vergleichbare" (und kostenlose/günstige) Alternativen, gerade für einfache Webhosting-Angebote ohne SSH-Zugang, gibt es derzeit einfach fast gar nicht.

PHP7 gibt einen ordentlichen Performance-Boost, der auch mal dringend nötig war.


----------



## MaxRink (7. Dezember 2015)

Trotzdem performt HHVM in vielen Fällen besser


----------



## RicoBrassers (7. Dezember 2015)

MaxRink schrieb:


> Trotzdem performt HHVM in vielen Fällen besser



Meist geben sich HHVM und PHP7 nicht viel, im Vergleich zu PHP5. Ich würde mal behaupten, HHVM und PHP7 arbeiten im Schnitt gleich schnell. Mal gewint HHVM, mal PHP7.


----------



## MaxRink (7. Dezember 2015)

Es glt immernoch, dass PHP mehr CPU und HHVM mehr RAM benötigt. Und mehr RAM ziehe ich persönlich vor


----------



## RicoBrassers (7. Dezember 2015)

MaxRink schrieb:


> Es glt immernoch, dass PHP mehr CPU und HHVM mehr RAM benötigt. Und mehr RAM ziehe ich persönlich vor



Kann sein, kann auch sein, dass mit PHP7 die "Lücke" weiter geschlossen wird/wurde. Ich denke mal, dass man noch etwas abwarten muss, um richtige Schlüsse ziehen zu können.
Eventuell kommt in den nächsten paar Tagen auch noch ein HotFix, wodurch weniger CPU-Last erzeugt wird, wer weiß 

Jedenfalls wurde mit PHP7 einiges verbessert, es ist eigtl. nicht geändert worden, was man wirklich als Negativ-Aspekt bewerten könnte. 

Edit: Für PHP7 spricht natürlich noch, dass der Großteil der PHP5-Anwendungen ohne Update von der Performance profitiert (keine Ahnung, wie das bei HHVM ist, habe damit noch nie gearbeitet.  )


----------



## Laudian (7. Dezember 2015)

RicoBrassers schrieb:


> Liegt aber eher daran, dass die Programmierer der Apps einfach die Lücken nicht geschlossen haben.
> Den Großteil aller SQL-Injections kann man in PHP schon mit einem einfachen
> 
> ```
> ...



Jetzt ist die Frage: Wieso ist das nicht längst Standardverhalten in neuen Versionen der Sprache ?

In PHP ist einfach so unendlich viel Ballast enthalten um die Abwärtskompatibilität zu gewährleisten... Nach So vielen Jahren muss man da halt einfach mal drauf pfeifen und die Leute zu ihrem Glück zwingen.


----------



## RicoBrassers (7. Dezember 2015)

Laudian schrieb:


> Jetzt ist die Frage: Wieso ist das nicht längst Standardverhalten in neuen Versionen der Sprache ?
> 
> In PHP ist einfach so unendlich viel Ballast enthalten um die Abwärtskompatibilität zu gewährleisten... Nach So vielen Jahren muss man da halt einfach mal drauf pfeifen und die Leute zu ihrem Glück zwingen.



Ganz einfach - weil man manchmal eben SQLi "erzwingen" möchte - warum auch immer. Ich finde aber, dass das so am Besten ist.
1.: Die Entwickler müssen/sollten sich mit SQLi auseinandersetzen und verstehen, was dahinter steckt.
2.: Man hat genug Freiheiten, falls man es absichtlich nicht haben möchte (z.B. Demonstrationszwecke? Keine Ahnung )

Edit: Mit PHP7 fliegt ja schon etwas Ballast raus.  z.B. MySQL-Unterstützung. Stattdessen muss man halt MySQLi (oder andere Datenbank) benutzen.


----------



## Laudian (7. Dezember 2015)

RicoBrassers schrieb:


> Ganz einfach - weil man manchmal eben SQLi "erzwingen" möchte - warum auch immer.



Ja, aber dann soll doch bitteschön die sichere Variante Standard sein und nicht andersrum...



RicoBrassers schrieb:


> 1.: Die Entwickler müssen/sollten sich mit SQLi auseinandersetzen und verstehen, was dahinter steckt.



Wenn wir uns mit allem auseinandersetzen wollen, können wir auch gleich wieder in Assembler schreiben.
Eine High-Level Programmiersprache soll dem Programmierer die Arbeit erleichtern, nicht neue Probleme schaffen...

Aber freut mich zu hören, dass das alte MySQL Modul endlich rausgeflogen ist anstatt das man weiterhin 2 Module parallel in der Standardbibliothek anbietet, von denen eines nicht benutzt werden sollte...


----------



## Zeiss (7. Dezember 2015)

Ap0ll0XT schrieb:


> Anstatt immer nur das negative Fallobst aus dem  riesen Salat zu picken versuch auch mal, die Rosinen zu erwischen. Da  sind so einige gute Änderungen bei.





lowskill schrieb:


> Bevor ich mir Rosinen aus dem Kompost picken muss, wähle ich lieber gleich eine andere Sprache.



Da hast Du es @Ap0ll0XT. PHP ist und bleibt einfach nur eine Bastelkiste, nicht mehr und nicht weniger.



Laudian schrieb:


> Wenn wir uns mit allem auseinandersetzen wollen,  können wir auch gleich wieder in Assembler schreiben.



Das hätte einen sehr großen Vorteil: PERFORMANCE und man weiß ganz genau, was man da treibt.



Laudian schrieb:


> Eine High-Level Programmiersprache soll dem  Programmierer die Arbeit erleichtern, nicht neue Probleme  schaffen...



Und genau das tut sie leider nicht all zu oft. In der HighSprache ist es  einfach eine Anwendung kurz mal "zusammen zu rotzen", aber sobald es an  die Optimierungen geht, steht man allein im Wald. Dann gibt es 1000  Frameworks, für alles mögliche, die setzt man sehr gern ein und schleppt  mit der Zeit einen riesigen Ballast mit sich rum. Auch hier, viel  Erfolg beim Ausmisten und optimieren.



Laudian schrieb:


> Aber freut mich zu hören, dass das alte  MySQL Modul endlich rausgeflogen ist anstatt das man weiterhin 2 Module  parallel in der Standardbibliothek anbietet, von denen eines nicht  benutzt werden sollte...



Ich weiß nicht, warum es ein Nachteil sein soll, dass man eine "depricated" Schnittstelle im Code drin hat.


----------



## Laudian (7. Dezember 2015)

Der Nachteil ist, dass viele Leute diese Schnittstelle benutzt haben, weil sie in der Standardbibliothek vorhanden ist.
Meinetwegen kann man sie ja drinne lassen, aber zumindest sollte es bei der Ausführung zu einem Fehler kommen, wenn nicht in irgendeiner Config Datei ein Wert auf "Ja, ich möchte dass meine Datenbank für Injections anfällig ist" gesetzt ist.

Eine bekannte Sicherheitslücke der Abwärtskompatibilität wegen nicht aus dem Code zu entfernen ist einfach gemeingefährlich. Man sieht ja, wie viele Seiten nach wie vor für SQL-Injections anfällig sind. Das wären wahrscheinlich um einiges weniger, wenn man die MySQL-Bibliothek durch die MySQLi-Bibliothek ersetzt hätte anstatt sie parallel anzubieten.


----------



## TessaKavanagh (8. Dezember 2015)

es sind ja nicht zwei Module von denen man eins nicht betreiben sollte in PHP 5.6 es sind drei Module  bitte PDO nicht übersehen, m.E. die beste Schnittstelle zu Datenbanken für PHP. Für SQL sollte man doch eh soweit möglich nur prepared Statements verwenden, was die Sicherheit bedeutend erhöht. Das Problem ist nicht PHP an sich sondern die 2,5Mio dermaßen veralteten Tutorials im Internet die nicht mehr aktualisiert werden und Codebeispiele enthalten.


----------



## RicoBrassers (8. Dezember 2015)

Ich vermute mal, dass das Ganze im Bezug auf SQLi nicht unbedingt der Fehler von PHP ist, sondern eher von (My)SQL. Immerhin führt der Datenbankenserver die Anfrage aus und müsste/sollte diese vorher Filtern. Dann wären *alle* SQLi-Lücken in allen Programmiersprachen gefixt. 

@TessaKavanagh Ganz ehrlich - ich habe noch nie verstanden, wie Prepared Statements helfen sollen, die Sicherheit zu verbessern. Ich glaube, dafür bin ich schlicht zu dämlich


----------



## Laudian (8. Dezember 2015)

Soweit ich das verstanden habe, werden bei prepared Statements Anweisung und Parameter getrennt voneinander übergeben und dadurch sichergestellt, dass eine Anweisung nicht als Parameter "injected" wird.


----------



## bingo88 (8. Dezember 2015)

Laudian schrieb:


> Soweit ich das verstanden habe, werden bei prepared Statements Anweisung und Parameter getrennt voneinander übergeben und dadurch sichergestellt, dass eine Anweisung nicht als Parameter "injected" wird.


Im Prinzip läuft das so ab. Das Kommando wird vorkompiliert, enthält aber Platzhalter für die Paramterwerte. Die werden dann einfach eingefügt und können am (vorkompilierten) Code nichts mehr ändern. Man bekommt so nicht nur einen automatischen SQL Injection Schutz, sondern bei Mehrfachverwendung der Query ist das sogar effizienter, da nur noch die Parameterwerte getauscht werden müssen.


----------



## Zeiss (8. Dezember 2015)

Laudian schrieb:


> Eine bekannte Sicherheitslücke der  Abwärtskompatibilität wegen nicht aus dem Code zu entfernen ist einfach  gemeingefährlich. Man sieht ja, wie viele Seiten nach wie vor für  SQL-Injections anfällig sind. Das wären wahrscheinlich um einiges  weniger, wenn man die MySQL-Bibliothek durch die MySQLi-Bibliothek  ersetzt hätte anstatt sie parallel anzubieten.



Das ist die Frage, wie entwickle ich. Gerade im DB-Umfeld sollte man  anders denken, gerade wegen den SQL-Injections. Man kann auch mit der  MySQL-Lib sauber und sicher entwickeln, man muss nur eben einpaar Sachen  mehr beachten, wie zum Beispiel kein SQL-Code (also Statements)  ausführen, sondern über PreparedStatement gehen und dann die  Bind-Variablen einsetzen und Feuer. Wer es anders macht, hat was nicht  verstanden.



RicoBrassers schrieb:


> @TessaKavanagh Ganz  ehrlich - ich habe noch nie verstanden, wie Prepared Statements helfen  sollen, die Sicherheit zu verbessern. Ich glaube, dafür bin ich schlicht  zu dämlich



Es ist eigentlich ganz einfach. Du hast ein Stement wie zum Beispiel (das ist jetzt Java, aber Prinzip ist derselbe):


```
sqlString = "select * from kunde where id = ?";
```

Das  Dng "preparierst" Du, der Statement wird kompiliert. Das ? ist dabei  der Platzhalter, wo der Wert eingesetzt wird. Im nächsten Schritt setzt  Du den Wert ein:


```
PreparedStatement prepStat = conn.prepareStement (sqlString);
prepStat.setInt (1, 17);
```

Dabei  sagst Du welcher Wert an welche Stelle im SQL eingesetzt wird, hier  wird eine 17 an die Stelle 1 (gibt ja nur die) eingesetzt.

Danach

```
ResultSet rs = prepStatement.executeQuery();
```

Und Dein Resultset landet in rs, fertig.

PreparedStatement hat mehrere Vorteile, zum einen Sicherheit, zum Anderen ist es für die DB auch einfacher (das Statement an sich ist derselbe, nur die Bind-Variablen ändern sich) und zum Dritten kann man sie batchen.


----------



## RicoBrassers (8. Dezember 2015)

Ah okay, danke. 
Also im Grunde fast wie ein String.format/printf, nur für SQL-Statements?

Mal schauen, ob ich mich dazu überreden kann, PreparedStatements in meinen nächsten Projekten zu verwenden. Vermutlich werde ich aus Gewohnheit bei den Escape-Strings bleiben


----------



## Zeiss (8. Dezember 2015)

Ja, mehr oder weniger.

Ich entwickle für Oracle, da wird es immer genommen, allein schon Performance wegen.


----------



## lowskill (9. Dezember 2015)

Zeiss schrieb:


> Laudian schrieb:
> 
> 
> > Wenn wir uns mit allem auseinandersetzen wollen, können wir auch gleich wieder in Assembler schreiben.
> ...



War das jetzt Ironie?


----------



## Zeiss (9. Dezember 2015)

Nein, das war keine Ironie.


----------



## OutOfMemory (9. Dezember 2015)

Zeiss schrieb:


> Da hast Du es @Ap0ll0XT. PHP ist und bleibt einfach nur eine Bastelkiste, nicht mehr und nicht weniger.



Das ist einfach nur Ignoranz. Nicht mehr und nicht weniger. Gefühlt 80% der Webseiten etc. werden mit PHP betrieben. Ruby ist ne tolle Sprache, verwendet aber kein Schwein. NET oder Java im Web Bereich ? Ne danke. Hat seinen Grund warum das kein Mensch macht. Jemals was über eine große Sicherheitslücke bei Facebook gelesen ? Ne ? Wenn man mit PHP richtig programmiert hat man oben genannte Probleme auch nicht. Du verteufelst ja auch keine Autos weil man damit Menschen überfahren kann.



Laudian schrieb:


> Der Nachteil ist, dass viele Leute diese Schnittstelle benutzt haben, weil sie in der Standardbibliothek vorhanden ist.
> Meinetwegen kann man sie ja drinne lassen, aber zumindest sollte es bei der Ausführung zu einem Fehler kommen, wenn nicht in irgendeiner Config Datei ein Wert auf "Ja, ich möchte dass meine Datenbank für Injections anfällig ist" gesetzt ist.



Alles was als decprecated markiert ist löst eine notice/warning aus. Sofern diese nicht unterdrückt werden durch die besagte Config (display_errors, error_reporting).


----------



## DarkMo (9. Dezember 2015)

Zeiss schrieb:


> Es ist eigentlich ganz einfach. Du hast ein Stement wie zum Beispiel (das ist jetzt Java, aber Prinzip ist derselbe):
> 
> 
> ```
> ...



Aber geht das nich auch mit normalem sql? Ich hab meinetwegen ein

```
$sql = "select * from table where id = ";
```
Das wäre doch grundsätzlich erstmal genau das gleiche. Ich habe meinen vorbereiteten sql-string und kann da nun was anhängen.

```
$sql.=$var;
```
Schon hab ich meinen Wert eingesetzt ^^

So, mir fallen auf Anhieb 1000 Unterschiede ein, was die Bequemlichkeit betrifft. Hier ists simpel, weil ich ja einfach was hinten anhäng. Bei mehreren Werten/komplexeren Abfragen wirds natürlich frickelig. Da könnte man mit ner Klassenstruktur und Objekten arbeiten. Aber spätestens dann hätte man doch genau das gleiche erreicht? WO ist da der Unterschied?

Wegen der Sicherheit und alten Turorials: dass man das nicht so simpel macht, wie hier im Bspw ist ja wohl hoffentlich klar und wird mE auch eigentlich überall erwähnt. Sowas konnte man doch auch mit alten Methoden absichern. addslashes, stripslashes, htmlentities oder was es da nich alles an funktionen gab, damit ein beliebiger String eben NICHT das eigentliche Statement abändern kann.

Wie gesagt: Bequemer mags sein, aber von der Sicherheit läufts doch aufs gleiche hinaus oder? Ehrlich gesagt würds mich auch garnich wundern, wenn das nix weiter is, wie eine Klassenstruktur, die intern auch wieder nur die alten Methoden nutzt ^^ Nur eben, dass man sich selber um die Sicherheitsaspekte nich mehr zu kümmern braucht.


----------



## lowskill (9. Dezember 2015)

Zeiss schrieb:


> Nein, das war keine Ironie.



Ah, ja. Gibt sicher viele Programmierer, die auf ASM-Ebene besser optimieren als ein moderner Compiler. Wäre schon interessant, wie viel Prozent langsamer diese "optimierten" Programme im Durchschnitt laufen.


----------



## RicoBrassers (9. Dezember 2015)

DarkMo schrieb:


> Aber geht das nich auch mit normalem sql? Ich hab meinetwegen ein
> 
> ```
> $sql = "select * from table where id = ";
> ...



Aber bei deiner Variante könnte man mit SQLi arbeiten.

```
$var="1 or 1=1;"
$sql.=$var;
```


----------



## DarkMo (9. Dezember 2015)

aber konnte man "var" nicht so absichern (quasi escapen als blöden vergleich ^^ hab scho lang nich mehr mit php und sql gearbeitet >< ), dass das or eben NICHT ausgewertet wurde? kann mir einfach nich vorstellen, dass das vorher nich ging und ne neue erfindung wäre ^^


----------



## RicoBrassers (9. Dezember 2015)

DarkMo schrieb:


> aber konnte man "var" nicht so absichern (quasi escapen als blöden vergleich ^^ hab scho lang nich mehr mit php und sql gearbeitet >< ), dass das or eben NICHT ausgewertet wurde? kann mir einfach nich vorstellen, dass das vorher nich ging und ne neue erfindung wäre ^^



Ja, man könnte $var vorher noch escapen, das ist richtig. 

```
$var=$db->real_escape_string($var);
```
Oder so ähnlich.


----------



## Zeiss (9. Dezember 2015)

OutOfMemory schrieb:


> Das ist einfach nur Ignoranz. Nicht mehr und  nicht weniger. Gefühlt 80% der Webseiten etc. werden mit PHP betrieben.  Ruby ist ne tolle Sprache, verwendet aber kein Schwein. NET oder Java im  Web Bereich ? Ne danke. Hat seinen Grund warum das kein Mensch macht.  Jemals was über eine große Sicherheitslücke bei Facebook gelesen ? Ne ?  Wenn man mit PHP richtig programmiert hat man oben genannte Probleme  auch nicht. Du verteufelst ja auch keine Autos weil man damit Menschen  überfahren kann.



Und wieviele von diesen 80% sind anfällig? Nur weil es jemand macht, heißt es noch lange nicht dass es gut ist. PHP ist super einfach und deswegen "kann" so gut wie jeder. PHP erlaubt Schweinereien, die in anderen Sprachen nicht gehen. Ich sage nur "implizite Variablendeklaration"... grausam.

eBay ist übrigens in C++ entwickelt, rennt wie Schwein und skaliert bombastisch... Und Facebook ist NICHT in PHP programmiert... sondern einer an PHP basierten Sprache, die eine Mischung aus PHP, Java und C#. Und jetzt rate mal warum das gemacht wurde?

Und Java im Webbereich funktioniert, richtig gut sogar. Dass es kein Mensch macht, ist einfach nur Schwachsinn. Die ganzen WebServices und SOAP und alles laufen unter was? Genau, zum größten Teil unter Java und meistens mit großen AppServer wie WebSphere oder WebLogic. 

Ich verteufle PHP nicht. Wenn ich schnell was zusammenrotzen will, dann nehme ich PHP. Für andere Web-Sachen nehme ich Java auf Tomcat mit einem vorgeschalteten NGINX.



DarkMo schrieb:


> Wie  gesagt: Bequemer mags sein, aber von der Sicherheit läufts doch aufs  gleiche hinaus oder? Ehrlich gesagt würds mich auch garnich wundern,  wenn das nix weiter is, wie eine Klassenstruktur, die intern auch wieder  nur die alten Methoden nutzt ^^ Nur eben, dass man sich selber um die  Sicherheitsaspekte nich mehr zu kümmern braucht.



Nein, eben nicht das Gleiche. Wenn Du von mir gezeigten Beispiel  nimmst, dann wird da nichts konkateniert, sondern in eine vorbereitete  "Struktur" eingesetzt.

Aus der SQL Sicht ist das:


```
$sql = "select * from table where id = ";
$sql.=$var;
```

etwas anderes als das hier:


```
String sqlString = "select * from kunde where id = ?";
PreparedStatement prepStat = conn.prepareStement (sqlString);
prepStat.setInt (1, 17);
```

zumindest bei Oracle. Und das ist für die spätere Optimierung und Ausführung von Bedeutung.



lowskill schrieb:


> Ah,  ja. Gibt sicher viele Programmierer, die auf ASM-Ebene besser  optimieren als ein moderner Compiler. Wäre schon interessant, wie viel  Prozent langsamer diese "optimierten" Programme im Durchschnitt  laufen.



Es kommt drauf an, wo man sich bewegt. Im embedded Bereich kann man da sehr viel rausholen. Und es ist dort auch Gang und Gäbe, dass man Object-Code noch mal an zeitkritischen Stellen nochmal überarbeitet. Man verwendet zum Beispiel vermehrt Makros anstelle von Funktionen.


----------



## OutOfMemory (9. Dezember 2015)

Zeiss schrieb:


> Und wieviele von diesen 80% sind anfällig? Nur weil es jemand macht, heißt es noch lange nicht dass es gut ist. PHP ist super einfach und deswegen "kann" so gut wie jeder. PHP erlaubt Schweinereien, die in anderen Sprachen nicht gehen. Ich sage nur "implizite Variablendeklaration"... grausam.
> 
> eBay ist übrigens in C++ entwickelt, rennt wie Schwein und skaliert bombastisch... Und Facebook ist NICHT in PHP programmiert... sondern einer an PHP basierten Sprache, die eine Mischung aus PHP, Java und C#. Und jetzt rate mal warum das gemacht wurde?
> 
> ...



Das stimmt nicht. Ja Facebook verwendet unter anderem auch Java und C++ usw. in unterschiedlichen Bereichen. Jede Firma verwendet unterschiedliche Sprachen. Ich code auch manches in Perl oder C# weil dort PHP einfach eine schlechte Wahl wäre. Aber Facebook basiert fast hauptsächlich auf PHP. Die haben HipHop bzw. HHVM bestimmt nicht entwickelt weil Sie Langeweile hatten. Keine Ahnung ob du mit "Mischung" HipHop meintest, aber das wäre dann auch falsch. Das ist nur der Interpreter. Das ist immer noch PHP-Code. Wenn du mir nicht glaubst, lies nach. Sicherlich  ist PHP in solch großen Dimensionen keine gute Wahl. Aber wir reden hier nicht nur von den Big-Playern.

Mit "kein Mensch" meine ich das es einfach kaum verbreitet ist und das ist nun mal Fakt. Im Webbereich dominiert PHP immer noch um Längen. Es gibt leider keine Statistik die Webservices/Websites/Apps o.ä genau unterscheidet. Aber PHP dominiert den gesamten Webbereich mit weitem Vorsprung. APS, Coldfusion, Java teilen den kleinen Rest unter sich auf.  Ich glaub dir das man was ordentliches mit Java auf die Beine stellen kann. Ich persönlich bin leider schon immer Java-Gegner gewesen. Schon bevor ich programmieren konnte. Da greife ich lieber zu C#. Trotzdem stelle ich die Sprache nicht als "rotz" dar oder "schmuddelkram". Was Sicherheit angeht steht Java auch nicht besser als PHP da. Flash/Java sind eigentlich die Hauptprobleme wenn es um Sicherheitslücken geht. Auch wenn es nicht mehr so schlimm ist wie es mal war.

Man darf auch nicht vergessen. PHP ist eine Skriptsprache. Sie mit Java und C++ zu vergleichen ist vollkommen falsch. Mit PHP kann ich mal eben ein Skript erstellen das eine Aufgabe erfüllt. Das heißt aber nicht das ich keine größeren Anwendungen damit erstellen kann.

Du widersprichst dir auch leider selbst "ich verteufle PHP nicht" und ein paar Wörter weiter "schnell was zusammenrotzen". Genau das ist die Mentalität die mir so auf die Nerven geht. Pure Ignoranz.


----------



## Zeiss (9. Dezember 2015)

OutOfMemory schrieb:


> *Ich persönlich bin leider schon immer Java-Gegner gewesen. Schon bevor ich programmieren konnte.*





OutOfMemory schrieb:


> *Du widersprichst dir auch leider selbst "ich verteufle PHP nicht" und ein paar Wörter weiter "schnell was zusammenrotzen". Genau das ist die Mentalität die mir so auf die Nerven geht. Pure Ignoranz.*



Danke für's Gespräch.


----------



## OutOfMemory (9. Dezember 2015)

Zeiss schrieb:


> Danke für's Gespräch.



Was ist daran falsch Java Programme nicht zu mögen ? Ich habe in keinem Wort gesagt das Java schlecht ist. C++ ist auch ne gute Sprache. Angenehm zu programmieren ist aber was anderes.


----------



## RicoBrassers (10. Dezember 2015)

Die Java-Applets haben für die ganzen Sicherheitsprobleme gesorgt und die sind heutzutage zum Glück fast komplett ausgestorben.
Webapps, die im Backend auf Java setzen sind um längen sicherer (werden ja auch nicht auf dem Client ausgeführt). So ist zum Beispiel Jenkins (eine der bekanntesten CI-Programme) ebenfalls in Java geschrieben.

Java an sich ist auch keine blöde Sprache. Ich tendiere eher zu sagen, dass es einfach nur eine subjektive Ablehnung ist. Entweder, weil man etwas anderes gewohnt ist oder weil man ständig von negativen Schlagzeilen (wegen den kack Applets) hört. Also ich persönlich kann z.B. in Java besser programmieren, als in C++. Liegt daran, dass ich mit C++ erst vor ein paar Monaten angefangen habe und in Java bereits seit guten 4-5 Jahren programmiere, oder einfach, weil man in Java idealerweise nur eine Datei pro Klasse braucht (C++ braucht ja Code und Header, wenn ich mich nicht irre). Wie gesagt, jeder hat seine persönlichen Präferenzen. 

Aber im Großen und Ganzen kann ich einigen hier nur zustimmen: Ich habe nichts gegen PHP, im Gegenteil. PHP war mal (nach Java) meine Lieblingssprache (Habe ich mich jetzt geoutet?).
Ich benutze sie derzeit auch nur, um einfachste Formulare oder Datenbankverbindungen zu schreiben. Für größere Projekte verwende ich mittlerweile NodeJS.
Auch wenn sich das _eventuell_ dank PHP7 wieder etwas ändern könnte. 

Blöde Frage: Man kann mit C++ auch im Web arbeiten (Backend)? Wusste ich noch gar nicht. Bisher war mir das nur von Asp.NET bekannt (Visual Basic, C#).


----------



## DarkMo (10. Dezember 2015)

Zeiss schrieb:


> Aus der SQL Sicht ist das:
> 
> 
> ```
> ...



das klingt etwas verquer ^^ WIE der anfrage string zusammen gesetzt wird, kann der DB herzlich egal sein, oder nich? die DB erhält nur die Anfrage. um konkret zu werden müsstest du einen konkreten endgültigen anfrage-string mal "malen". was wird bei einem prepared statement aus "1 or 1=1"? und ich bin mir sehr sehr sicher, dass man diese anfragestruktur auch mit "normalem" php bla hinbekommt. im endeffekt wird der ganze teil "1 or 1=1" in irgendeiner weise im string markiert, so dass die DB das or NICHT auswertet. und das kannste auch in nem ganz normalen string machen ^^ DAS meinte ich.

prepared statements mögen einen bequemen weg darstellen, wenn man sich anstrengt, bekommt man das ohne aber auch hin (bin ich der meinung).

bspw schreibt man halt nicht
select * from kunde where id = ? 
sondern
select * from kunde where id = '?'

schon steht das or innerhalb der anführungszeichen und der ganze inhalt der variablen wird als wert angesehn (welcher in dem fall schlicht ungültig ist). hab schon länger nix mehr mit datenbanken gemacht, daher weiß ich jetz nich, ob das so ausreichend ist und stimmt, aber das prinzip sollte deutlich werden.


----------



## RicoBrassers (10. Dezember 2015)

PHP: Prepared Statements - Manual

Der Vorteil von PreparedStatements ist halt, dass das "Query template", also unser "select * from kunde where id = ?" nur ein einziges Mal zum DB-Server geschickt wird (Wenn man die Query häufiger ausführt).
Wenn man nur eine einzelne Query abschickt, mag ein normales Escapen reichen, aber wenn man ein Template häufiger (hintereinander) benutzt, kann man mit PreparedStatements eine etwas bessere Performance erreichen.


----------



## bingo88 (10. Dezember 2015)

Das hatte ich doch alles schon in Post #19 geschrieben


----------



## DarkMo (10. Dezember 2015)

asö! na das is ja dann auch was andres ^^ davon hat aber bisher irgendwie nie einer gesprochen >< also wird diese vorbereitete anfrage schon an die db geschickt und dort wird dann nur noch die gewünschte variable hinzugefügt? hmm, aber dennoch muss die DB bei jeder neuen variable ne neue anfrage intern erstellen, dächt ich. also man spart nen bissl an übertragungs-bandbreite und die db weis eben ganz genau, dass das, was da folgt nur werte sind (was dann wirklich der entscheidende vorteil is). aber direkte performance-zuwächse könnt ich mir gerade dennoch nich vorstellen.

dazu müsste die db ja eine vollständige view der "ungefilterten" (also ohne variable filter) anfrage abspeichern und diese dann je nach variablem filter erneut durchackern (aber eben ein kleiner datenbestand wie die ganze db ^^). dennoch würde man doch aber irgendwann unweigerlich auf veralteten daten arbeiten. eigentlich unvorstellbar, dass das so abläuft.


----------



## RicoBrassers (10. Dezember 2015)

bingo88 schrieb:


> Das hatte ich doch alles schon in Post #19 geschrieben



Weiß ich, ich habe es auch nur nochmal aufgefasst, weil es gerade passend war. 
Argument-Recycling 

@DarkMo


> MySQL 5.7 provides support for server-side prepared statements. This support takes advantage of the efficient client/server binary protocol. Using prepared statements with placeholders for parameter values has the following benefits:
> 
> Less overhead for parsing the statement each time it is executed. Typically, database applications process large volumes of almost-identical statements, with only changes to literal or variable values in clauses such as WHERE for queries and deletes, SET for updates, and VALUES for inserts.
> 
> Protection against SQL injection attacks. The parameter values can contain unescaped SQL quote and delimiter characters.


MySQL :: MySQL 5.7 Reference Manual :: 13.5 SQL Syntax for Prepared Statements


----------



## DarkMo (10. Dezember 2015)

aaah, daher weht da der wind. also isses wie vermutet, dass dennoch jedesmal eine anfrage gestartet wird, diese aber eben "in groben zügen" schon bekannt ist und das dbms so schlau ist, daraus einen geschwindigkeitsvorteil zu ziehen. sehr interessant. danke für die geduld und aufklärung


----------



## bingo88 (10. Dezember 2015)

DarkMo schrieb:


> asö! na das is ja dann auch was andres ^^ davon hat aber bisher irgendwie nie einer gesprochen >< also wird diese vorbereitete anfrage schon an die db geschickt und dort wird dann nur noch die gewünschte variable hinzugefügt? hmm, aber dennoch muss die DB bei jeder neuen variable ne neue anfrage intern erstellen, dächt ich. also man spart nen bissl an übertragungs-bandbreite und die db weis eben ganz genau, dass das, was da folgt nur werte sind (was dann wirklich der entscheidende vorteil is). aber direkte performance-zuwächse könnt ich mir gerade dennoch nich vorstellen.
> 
> dazu müsste die db ja eine vollständige view der "ungefilterten" (also ohne variable filter) anfrage abspeichern und diese dann je nach variablem filter erneut durchackern (aber eben ein kleiner datenbestand wie die ganze db ^^). dennoch würde man doch aber irgendwann unweigerlich auf veralteten daten arbeiten. eigentlich unvorstellbar, dass das so abläuft.


Performancezuwächse kannst du nur bekommen, wenn du dieselbe Query mehrfach verwendest. Sobald du die Anzahl der Parameter oder deren Typ änderst, brauchst du nämlich eine neue Query und kannst die alte nicht recyclen.

Edit:


----------



## DarkMo (10. Dezember 2015)

joa, so langsam durchsteig ichs. also werden qausi die benötigten tabellen usw nicht mehr neu "ausgelesen", das kennt er alles schon. er passt dann nur noch die filter an und rödelt drüber. sehr äh "kindlich" dargestellt ^^


----------



## bingo88 (10. Dezember 2015)

Erst einmal beschränkt sich das nur auf die Query. Wenn du eine normale Query an das DBMS übergibts, muss das die ja erst mal parsen, kompilieren und optimieren. Bei Prepared Statements wird quasi das Ergebnis dieser Verarbeitung gespeichert, so dass man die gleiche Query mehrfach ohne ein erneute Verarbeitung ausführen kann. Im Detail ist das natürlich wieder etwas komplizierter aber im Prinzip läuft das so ab.

Edit: Hier gibt es eine brauchbare Erklärung zu dem Thema.


----------



## lowskill (10. Dezember 2015)

Zeiss schrieb:


> Es kommt drauf an, wo man sich bewegt. Im embedded Bereich kann man da sehr viel rausholen. Und es ist dort auch Gang und Gäbe, dass man Object-Code noch mal an zeitkritischen Stellen nochmal überarbeitet. Man verwendet zum Beispiel vermehrt Makros anstelle von Funktionen.



Die Ursprüngliche Aussage war extrem allgemein gehalten. Wenn man diese Aussage nun so stark relativiert, wie in dem zitierten Text, kann ich durchaus zustimmen.



OutOfMemory schrieb:


> Mit "kein Mensch" meine ich das es einfach kaum verbreitet ist und das ist nun mal Fakt. Im Webbereich dominiert PHP immer noch um Längen.


Unter den 12- bis 18-Jährigen? Ja, da hast du sicher Recht. Liegt wohl nicht zuletzt daran, dass es mit praktisch jedem Hosting-Paket angeboten wird und entsprechend billig zu haben ist.



OutOfMemory schrieb:


> APS, Coldfusion, Java teilen den kleinen Rest unter sich auf.


Du meinst den "kleinen" Enterpriese-Rest? (APS = ASP.NET?)



OutOfMemory schrieb:


> Ich persönlich bin leider schon immer Java-Gegner gewesen. Schon bevor ich programmieren konnte.


Diese Aussage disqualifiziert dich eigentlich für jede weitere Diskussion. Du warst also "Gegener" von etwas, das du zu diesem Zeitpunkt weder verstehen noch einschätzen oder vergleichen konntest. Das bedarf eigentlich keines weiteren Kommentars.



OutOfMemory schrieb:


> Was Sicherheit angeht steht Java auch nicht besser als PHP da. Flash/Java sind eigentlich die Hauptprobleme wenn es um Sicherheitslücken geht.


Wie passen denn nun Flash und Java(-Applets?) ins Bild?



OutOfMemory schrieb:


> Genau das ist die Mentalität die mir so auf die Nerven geht. Pure Ignoranz.


Dunning-Kruger-Effekt


----------



## Zeiss (10. Dezember 2015)

RicoBrassers schrieb:


> Blöde Frage: Man kann mit C++ auch im Web arbeiten (Backend)? Wusste ich  noch gar nicht. Bisher war mir das nur von Asp.NET bekannt (Visual  Basic, C#).



Klar, warum denn nicht? Sagt Dir cgi (common gateway interface)  etwas? Was Du dahinter schnallst, ist völlig egal. Meistens wird hier  Perl genommen, aber wir hatten auch schon Projekte, wo C zum Einsatz  kam.



DarkMo schrieb:


> aaah, daher weht da der wind. also  isses wie vermutet, dass dennoch jedesmal eine anfrage gestartet wird,  diese aber eben "in groben zügen" schon bekannt ist und das dbms so  schlau ist, daraus einen geschwindigkeitsvorteil zu ziehen. sehr  interessant. danke für die geduld und aufklärung



Ich erkläre es Dir mal, wie es in Oracle passiert. Wie es andere machen, keine Ahnung.

Also,  unser Statement: select * from kunde where name = ?; (ich habe extra  den Namen genommen, weil es dann vielleicht deutlicher wird). Das '?'  ist hierbei eine Bindvariable. Also, das SQL kommt an, der Optimizer  schaut es sich an, parst es (hard + soft), optimiert es (ca 50.000 mal)  und legt das Statement im Cache ab. WICHTIG: Der Wert der Variable wird  nicht berücksichtigt! Jetzt führst Du dasselbe Statement noch mal aus,  Optimizer merkt, dass genau dieses Statement schon im Cache liegt und  nicht geparst und optimiert werden muss. Also, wird das Statement aus  dem Cache genommen und ausgeführt.

Jetzt setzt Du die Bedienung  direkt in das SQL rein: select * from kunde where name = 'Müller'; und  führst es aus. Das Statement wird geparst (hard + soft), optimiert (ca  50.000mal), im Cache abgelegt und dann ausgeführt. Jetzt führst Du das  SQL nochmal aus, aber anstelle von Müller schreibst Du Schulze rein. Für  den Optimizer ist das zweite Statement wieder ein Neues, obwohl es sich  ja nur der Filter geändert hat. Also beginnt das Spiel wieder von  vorne. Das ist der Unterschied zwischen "Bindvariablen" und "Literalen".  Wenn Interesse besteht, kann ich es Dir noch genauer erklären.


----------



## OutOfMemory (10. Dezember 2015)

lowskill schrieb:


> Unter den 12- bis 18-Jährigen? Ja, da hast du sicher Recht. Liegt wohl nicht zuletzt daran, dass es mit praktisch jedem Hosting-Paket angeboten wird und entsprechend billig zu haben ist. Du meinst den "kleinen" Enterpriese-Rest? (APS = ASP.NET?)



Usage Statistics and Market Share of Server-side Programming Languages for Websites, December 2015 
TIOBE Software: The Coding Standards Company
https://de.wikipedia.org/wiki/PHP (siehe Punkt Verbreitung)
PHP just grows & grows | Netcraft
Historical trends in the usage of server-side programming languages, December 2015
http://githut.info/

Nur weil die großen auf bestimmte Technologie setzten, bedeutet es immer noch nicht das es die Mehrheit ist. Ob Forum, Blog, Wiki oder Onlineshop und was es noch alles so gibt. Hinter denen steckt fast immer PHP. Warum meinst du den gibt es so viele günstige Hosting Angebote für PHP ? Angebot und Nachfrage.



lowskill schrieb:


> Diese Aussage disqualifiziert dich eigentlich für jede weitere Diskussion. Du warst also "Gegener" von etwas, das du zu diesem Zeitpunkt weder verstehen noch einschätzen oder vergleichen konntest. Das bedarf eigentlich keines weiteren Kommentars.



Ich habe es einfach nicht gemocht und möglichst gemieden. Wortwahl war vielleicht nicht die beste. Das hatte ich aber bereits klargestellt.



lowskill schrieb:


> Wie passen denn nun Flash und Java(-Applets?) ins Bild?



PHP wird als Sicherheitsproblem dargestellt. Bei Java und anderen Sprachen (Flash) gibt es aber auch einige Probleme.



lowskill schrieb:


> Dunning-Kruger-Effekt



Dir ist schon bewusst das es dann wohl auch auf dich zutrifft ? Immerhin willst du ja nicht akzeptieren das PHP Marktführer ist.


----------



## Ap0ll0XT (11. Dezember 2015)

DarkMo schrieb:


> aaah, daher weht da der wind. also isses wie vermutet, dass dennoch jedesmal eine anfrage gestartet wird, diese aber eben "in groben zügen" schon bekannt ist und das dbms so schlau ist, daraus einen geschwindigkeitsvorteil zu ziehen. sehr interessant. danke für die geduld und aufklärung


Naja der Geschwindigkeitsvporteil ist ja nur bedingt da. Es kommt, wenn man die SQL-Statements richtig ausformt selten dazu, das ein und das selbe Statement verwendet werden muss. Du darfst nicht vergessen, das gerade bei PHP die Datenbankverbindungen bei jeden Request wieder geschlossen werden und dadurch die Informationen verfallen.

Das wichtigste bei Prepared-Statements ist einfach der, das unser SQL-Statement getrennt von den Werten vorkompilliert werden, wodurch SQL-Anweisungen in den übergebenen Werten ungültig werden.

Um das mal zu verdeutlichen:

```
$sql = "SELECT * FROM accounts WHERE password=";
$sql .= $_POST["password"]; // Übergabe von "0 or 1=1". Die hintere or-Anweisung wird auch ausgeführt
```

So mit Prepared-Statement:

```
$sql = "SELECT * FROM accounts WHERE password=:pwstr";
$stmt = $db_pdo->prepare($sql);
// Das obere Statement wird kompilliert. Nehmen wir mal an, es wird in Token übersetzt (was nicht der realität entspricht, aber so ist es verständlicher):
// T_SELECT "*" T_FROM "accounts" T_WHERE "password" T_COMP T_VARIABLE:pwstr

$stmt->execute(array( ":pwstr" => $_POST["password"] )); 
// Übergabe von "0 or 1=1". Die hintere or-Anweisung wird nicht ausgeführt. Der Interpreter versteht es in dem Stadium nicht
// Es wird sowas draus gemacht: T_SELECT "*" T_FROM "accounts" T_WHERE "password" T_COMP "0 or 1=1"
// Das Gleichheitszeichen müsste zum T_COMP werden und das or zum T_OR. Außerdem müsste die Anweisung in 3 Strings zerlegt werden.
```
Da aber Prepared nicht so arbeitet, wie ich es demonstriert habe, sondern deutlich effektiver, muss man für die Datenbank selbst kein Escaping der Werte mehr vornehmen. Denn SQL-Anweisungen werden innerhalb des kompilierten Statements nicht mehr verstanden, da diese Werte ausschließlich auch als solche erwartet und behandelt werden.

Und was die ganzen anderen hier betrifft, die sich wegen der Sprache den Kopf einschlagen. Ich frage mich echt, was der ganze Kram soll. PHP ist in sehr vielen Dingen einfach freier. In PHP kann man objektorientiert, prozedural oder in beidem arbeiten. Was für den einen ein schlechter Programmierstil ist, ist für andere eine ebenfalls funktionierende kreative Lösung. Und wer PHP nicht leiden kann, soll es einfach meiden. Ich arbeite jetzt schon seit etwa 10 Jahren mit PHP und es ist für mich bis heute noch die einzige Sprache für das Web, die mir auch beim programmieren Spaß macht. Mir macht es keinen Spaß, bei den Versuch, Probleme zu lösen ständig auf irgendwelche Debugger-/Compiler-Fehler zu treffen, weil die blöde Sprache mir vorkauen muss, wie ich ein Problem zu lösen habe. Wenn das ganze so weitergeht und die Sprachen noch strikter werden, brauch man dem Computer bald nur noch sagen, was man benötigt und er erzeugt den Code von alleine nach ISO- und DIN-Norm. Ob man das dann von Hand Tippt oder der Computer die Lösung generiert. Es würde bis auf die Bezeichner eh alles gleich aussehen.

Ich schweinere in Codes sogar sehr gerne rum. Ich tue alles, um Overheads zu minimieren. Am Ende muss das Ergebnis nur stimmen und es sollte sicher sein. Die Verantwortung dafür hat der Programmierer und nicht die Entwickler einer Programmiersprache. Diese muss nur Grundlegend sicher sein. Sie kann aber nicht für die Unsicherheit verantwortlich sein, die ein Programmierer in seine Software integriert hat!

Jetzt mit PHP 7 habe ich alle Singletons durch anonyme Klassen ersetzt. Callbacks werden fast nur noch mit anonymen Funktionen erstellt. Der Umfang an externen Hilfsbibliotheken ging dabei rapide zurück. Auch der neue Null-Coalescing Operator ?? findet aktuell regen Einsatz. Ich habe mit PHP meinen Spaß. Und egal ob VB.NET, Python oder Java. Mit alle diesen Sprachen will ich einfach im Web nicht arbeiten. Selbst für den Desktop habe ich mir andere Alternativen gesucht, anstatt diese Dinger zu benutzen. Das ist mir auch völlig schnuppe, ob Java, C#, VB.NET und Konsorten vor allem im Business-Bereich am weitesten verbreitet sind. Jeder soll sich da seinen eigenen Weg suchen.  Aber je mehr mir eine Sprache eine feste Arbeitsweise aufdrängen will oder sogar strikt einfordert, um so unsymparischer ist mir die Sprache bzw. dessen Debugger/Compiler/Interpreter. Ich hätte gerne in den ersten 2 Jahrzehnten des Computerzeitalters schon gelebt, wo damals die ganz großen der Szene mit "Schweinecode" noch das Computerzeitalter mitgeformt haben. Heute fehlt dem ganzen einfach die Seele. Aber wie ich schon gesagt habe. Das soll jeder für sich selbst entscheiden.

Viele Argumente sind vielleicht richtig. Aber diskutiiert bitte differenzierter. Denn nicht alle teilen eure Meinung und wenn jemand denkt, auf Grund einer Aussage diese Person für dieses Thema gänzlich zu disqualifizieren, dann ist das sein Bier. Aber denkt bitte daran, das eine solch entsprechende Aussage beleidigend ist. Nehmt eure Nasen bitte wieder runter!


----------



## Zeiss (11. Dezember 2015)

Wenn also eine Sprache von Dir sowas 


```
private static Integer i = 10;
```
anstelle von

```
$i = 10;
// dann kann ich ja auch sowas machen:
$i = "ich bin ein string...";
// geile Sache, eine und dieselbe Variable als ein Integer und dann auch als String. Ade Datentypisierung!
```

einfordert, ist sie Dir unsympathisch?

Sorry, aber das kann ich nicht nachvollziehen geschweige denn gutheißen. Jeder hat seinen Programmierstil und das soll auch so sein, aber es gibt sowas wie "wartbarer Code" und da sind solche Späße wie "rumschweinern im Code" schlicht und ergreifend verboten. Ich rede vom Business-Bereich, was man auf seinem eigenen PC macht, ist schnurz.

Und zum Thema "Codegenerierung": sowas gibt es schon und wird in manchen Bereichen der Softwareentwicklung sogar vorausgesetzt 

PHP hat seine Vorteile und Daseinsberechtigung, absolut, das will ich nicht abstreiten.


----------



## lowskill (11. Dezember 2015)

Bitte, er hat doch klargestellt, dass er sich vom "Business-Bereich" nicht bevormunden lassen will. Ein Freigeist muss auch mal "rumschweinern" dürfen, um sein Genie zum Ausdruck zu bringen. Wartbarkeit ist etwas für Amateure, nichts für Leute, die seit zehn Jahren mit PHP arbeiten. Und überhaupt, durch das Wegfallen des Compile-Schrittes erspart man sich Unmengen von potentiellen Fehlern und kann sich auf Laufzeitfehler konzentrieren, falls denn überhaupt welche auftreten sollten (die man bemerkt). Jetzt bitte keine Argumente mehr gegen PHP anführen  oder gar alternative Sprachen vorschlagen, sonst wächst seine Abneigung nur noch mehr an.


----------



## Zeiss (11. Dezember 2015)

Sehr sehr geil 

Du bist schuld, dass ich jetzt vom Lachen noch mehr Ohrenschmerzen habe (hatte am Montag eine Ohren-OP)


----------



## RicoBrassers (11. Dezember 2015)

Zeiss schrieb:


> Wenn also eine Sprache von Dir sowas
> 
> 
> ```
> ...



Naja, ich glaube aber, dass es is PHP nicht so schlimm wie in JS ist 



			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.


----------



## Zeiss (11. Dezember 2015)

Ist ja mehr oder weniger dasselbe, ich kann ja auch $i = '10' schreiben und habe meinen String. 

Einfach nur grausam.


----------



## RicoBrassers (11. Dezember 2015)

Zeiss schrieb:


> Ist ja mehr oder weniger dasselbe, ich kann ja auch $i = '10' schreiben und habe meinen String.
> 
> Einfach nur grausam.



Ging mir eher um die interne Handhabung vom PHP mit der Typeninkonsistenz.
Also ob PHP aus '10' + 2 nun 12, '12', '102' oder 102 macht, oder einfach ein Fehler ausgibt.

Das habe ich bisher noch nie getestet, werde ich aber vermutlich nochmal machen, dieses Wochenende. 
Aber wir schweifen ziemlich stark vom Thema ab.


----------



## Zeiss (11. Dezember 2015)

Bitte schön:


```
<?php

$i = 10;

echo $i;

echo "<br><br>";

$i = '10';

echo $i;
echo "<br><br>";

$i = '10' + 2;

echo $i;
echo "<br><br>";

$i = '10' + '2';

echo $i;
?>
```

Und was er ausgibt:



> 10
> 
> 10
> 
> ...



Man sieht natürlich nicht ob, es sich um einen String oder Int handelt.


----------



## DarkMo (11. Dezember 2015)

wird glaub ich '102' ^^
edit: ok, geirrt


----------



## Zeiss (11. Dezember 2015)

102 kriegt man, in dem man $i = '10' . '2'; hinschreibt, also "Stringkonkatination".


----------



## RicoBrassers (11. Dezember 2015)

Zeiss schrieb:


> 102 kriegt man, in dem man $i = '10' . '2'; hinschreibt, also "Stringkonkatination".



Stimmt, bei PHP macht man das ja so. 
Und hier ist der Vorteil von PHP: Unterschiedliche Operatoren für Stringkonkatenation und Addition. Somit ist eine Fehlerquelle der Typeninkonsistenz behoben.


----------



## DarkMo (11. Dezember 2015)

Jup, das fiel mir auch ein, als ich grad zur Tür raus war ^^


----------



## Laudian (13. Dezember 2015)

Ganz im Ernst, wenn "10"+2 überhaupt ausgeführt wird, ist das für mich ein ziemliches Manko. Und wenn aus "10"+"2" 12 wird (String + String = Int), dann ist das doch ein schönes Beispiel für alles, was an dieser Sprache verkehrt ist...

Mein Lieblingslink zu diesem Thema:
PHP: a fractal of badÂ*design / fuzzy notepad

Folgendes Verhalten würde ich übrigens von einer Programmiersprache erwarten, und siehe da wer liefert...


```
>>> [COLOR="#008000"]"10"+2
[COLOR="#FF0000"]Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    "10"+2
TypeError: Can't convert 'int' object to str implicitly
```


```
>>> 2+[COLOR="#008000"]"10"[COLOR="#FF0000"]Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    2+"10"
TypeError: unsupported operand type(s) for +: 'int' and 'str'
```


```
>>> [COLOR="#008000"]"10"+[COLOR="#4B0082"]str(2)
[COLOR="#0000FF"]'102'
```


```
>>> [COLOR="#4B0082"]int([COLOR="#008000"]"10")+2
[COLOR="#0000FF"]12
```


----------



## DarkMo (13. Dezember 2015)

was die einen daran hassen, lieben andere daran


----------



## lowskill (13. Dezember 2015)

Privat kann ja jeder rumfrickeln, wie er will.


----------



## Zeiss (13. Dezember 2015)

Laudian schrieb:


> Folgendes Verhalten würde ich übrigens von einer Programmiersprache erwarten, und siehe da wer liefert...



Dieses Verhalten hat auch so gut wie jede Programmiersprache, die hier angesprochen wurde(C/C++/C#/Java/...).


----------



## Laudian (13. Dezember 2015)

Dann sind das wohl alles recht vernünftige Sprachen... Bis auf PHP eben.

Sry, aber eine Sprache bei der "String + String = Int" gilt, kann ich nicht wirklich ernst nehmen.

Implizite Typenkonvertierung ist einfach ein Magnet für schwer auffindbare Fehler. Wie soetwas beabsichtigtes Verhalten sein kann, wird mir für immer ein Rätsel bleiben.


----------



## Zeiss (13. Dezember 2015)

Das sehe ich genau so wie Du.


----------



## RicoBrassers (14. Dezember 2015)

Laudian schrieb:


> Dann sind das wohl alles recht vernünftige Sprachen... Bis auf PHP eben.
> 
> Sry, aber eine Sprache bei der "String + String = Int" gilt, kann ich nicht wirklich ernst nehmen.
> 
> Implizite Typenkonvertierung ist einfach ein Magnet für schwer auffindbare Fehler. Wie soetwas beabsichtigtes Verhalten sein kann, wird mir für immer ein Rätsel bleiben.



An sich richtig.
Aber man betrachte es mal von der anderen Seite: So muss man Usereingaben (die eigentlich immer als String vorhanden sind) nicht erst prüfen und in einen Int umwandeln, wenn man Rechenschritte durchführen muss. Aber man kann, soweit ich mich entsinne, vorher natürlich eine Abfrage machen, ob denn beide Variablen gültige Ints sind, um andere Fehler zu vermeiden.
In meinen Augen würde es hier nur zu mehr Fehlern führen, wenn das + in PHP wie in anderen Sprachen zur String-Konkatenation benutzt werden würde.

Klar, eine Fehlerausgabe wäre auch möglich. Aber wie bereits gesagt: Zum Verarbeiten von Usereingaben empfinde ich dies als idealen Ansatz, anstatt gleich dem User einen fetten Fehler entgegenzuwerfen, der damit vermutlich nichtmal etwas anfangen kann.

Aber dieses Verhalten bei impliziter Typenkonvertierung ist immer noch besser als der Ansatz von JavaScript (jedenfalls in meinen Augen). 

Aber es ist trotzdem nicht richtig, eine Sprache deswegen als "unvernünftig" abzustempeln.
Nur mal so - Pythons Zwangseinrückungen sind auch nicht sooo das Wahre. 
Keine Sprache macht alles richtig, aber wir können ja eine Workgroup aufmachen und unsere eigene Sprache entwickeln und diese ganzen Fehler in dieser dann nicht einbauen.


----------



## Zeiss (14. Dezember 2015)

RicoBrassers schrieb:


> An sich richtig.
> Aber man betrachte es mal von der anderen Seite: So muss man Usereingaben (die eigentlich immer als String vorhanden sind) nicht erst prüfen und in einen Int umwandeln, wenn man Rechenschritte durchführen muss. Aber man kann, soweit ich mich entsinne, vorher natürlich eine Abfrage machen, ob denn beide Variablen gültige Ints sind, um andere Fehler zu vermeiden.
> In meinen Augen würde es hier nur zu mehr Fehlern führen, wenn das + in PHP wie in anderen Sprachen zur String-Konkatenation benutzt werden würde.
> 
> Klar, eine Fehlerausgabe wäre auch möglich. Aber wie bereits gesagt: Zum Verarbeiten von Usereingaben empfinde ich dies als idealen Ansatz, anstatt gleich dem User einen fetten Fehler entgegenzuwerfen, der damit vermutlich nichtmal etwas anfangen kann.



Das sehe ich anders. In der GUI weißt man doch, welche Werte (ob String oder Zahl) wo reinkommen. Also prüft man bei der Eingabe in die Felder die Werte und lässt nur das zu, was auch wirklich erlaubt ist. Dann im Code, sollte man es wirklich zusammensetzen wollen, castet man das Ganze ist das Thema ist erledigt.


----------



## RicoBrassers (14. Dezember 2015)

Zeiss schrieb:


> Das sehe ich anders. In der GUI weißt man doch, welche Werte (ob String oder Zahl) wo reinkommen. Also prüft man bei der Eingabe in die Felder die Werte und lässt nur das zu, was auch wirklich erlaubt ist. Dann im Code, sollte man es wirklich zusammensetzen wollen, castet man das Ganze ist das Thema ist erledigt.



Darauf kann man sich (leider) auch nicht verlassen. Ich hatte erst gestern ein Web-Formular der Telekom aufm Bildschirm, die haben einem E-Mailfeld nicht mal den Typ "email" verpasst ...


----------



## Zeiss (14. Dezember 2015)

Dass ist die QS von Telekom für den Eimer.


----------

