Abstimmung über Scalar Type Hints ist eröffnet

[SirSnyder]

https://wiki.php.net/rfc/scalar_type_hints

Type Hints ja, aber ich mag das declare nicht. Statt es konsequent durchzuziehen, wird nun dieses inkonsequente Verhalten vorgeschlagen. TypeHint "string" nimmt int, bool und float an. Einfach nur rumgefriemel und Mist.

[BlackScorp]

naja es ist wohl dazu da, dass man vielleicht den neuen Code den man einbaut, schon mit strikten typehints versehen kann, während man die anderen klassen nach und nach bearbeiten kann.

ich für mein Teil würde sowieso in meine index.php ganz oben hinschreiben

declare(strict_types=1); 

und dann meine Tests durchlaufen, die wollten wohl eine mischform machen und kein entweder oder fall.

[mermshaus]

Ich fand das beim Lesen gar nicht so schlecht. Der Ansatz mit dem declare kann ja offenbar auch die eingebauten PHP-Funktionen strikt typsiert machen. Das ist etwas, was ich in Diskussionen dazu noch nicht gesehen hatte, weil es natürlich ein gigantischer Bruch mit der Abwärtskompatibilität wäre, diese Funktionen insgesamt „strikt“ zu machen. (Kann aber sein, dass das in Hack auch so ähnlich funktioniert. Weiß das jemand?)

Dann habe ich eine Kritik dazu gelesen, die ich allerdings auch gar nicht so schlecht fand. (Bis zumindest auf die „das ist nicht PHP“-Argumente. Die bringe ich selbst auch manchmal, aber das sind irgendwie schon Totschlagargumente.)

Wenn nicht noch irgendwas passiert, wird das RFC aber in der Form wohl abgelehnt werden. (Woran die Leute konkret Anstoß nehmen, muss man sich leider immer von der Mailing-List zusammensuchen. Das können auch formale Gründe sein, die sich nicht konkret auf den Inhalt beziehen.) Zwei-Drittel-Mehrheit wird jedenfalls benötigt, aktuell steht es 17-20.

[erc]

Das ist ein schlechter Kompromiss. Was als Begründung für diesen Ansatz angegeben wird ist eigentlich fast alles irrelevant.

"Inkonsistens von PHP?"
PHP konsistent?

"Die anderen sagen sonst nein."
Bürokratie

"Bestehender Code könnte durch änderung am Interfaces nicht mehr funktionieren."
Wasser ist Nass.

Das einzige was von diesen Argumenten in meinen Augen relevant ist, ist: "People who do not like weak or strict type checking would be forced to deal with strictly or weakly type-checked libraries, respectively."

Das halte ich für berechtigt. Ich kann mir gut vorstellen das es einige geben wird die das übertreiben nutzen werden. Da ists dann auch nicht mehr weit zu

function mache_aus_zahl_schoenen_preis(float $value) {
    return number_format(...);
} 

und dann stehste plöztlich da und machst

$value = (float)($eingabe/10);
echo mache_aus_zahl_schoenen_preis($value); 

Herzlichen Glückwunsch. Da find ich die Möglichkeit zum deaktivieren der Typenprüfung ganz sinnvoll. Leider ist das aber bei dem Ansatz eine friss oder stirb Geschichte. Entweder deaktiviere ich die Typenprüfung für alles oder nix. (wer langeweile hat kann natürlich jeden Aufruf in ein declare() Block packen, aber das ist eher weniger praxistauglich.)

Natürlich bleibt dabei die Frage ob das jemals zu einem wirklichen Problem wird. Spaltet sich dadurch die Community auf in strict und weak Libs oder regelt sich das von allein?

[Suralc]

Strict oder Weak typehints werden es, so wie es derzeit auf der Liste aussieht (nur über die letzten beiden Monate gelesen, nicht wirklich ausgezählt) niemals alleine auf die erforderliche 2/3-Mehrheit schaffen. (Und falls doch nur aus einer "Besser als nichts"-Mentalität) Ich würde auch bezweifeln, das der zwei-Syntax-Ansatz überhaupt eine einfache Mehrheit erreichen würde:

function foo(int $a, (int)$b, int $c); 

Die derzeitige Alternative wird sich dann wohl in diese Richtung entwickeln :
https://wiki.php.net/rfc/dbc

Am erstaunlichsten ist aber, dass das "Reserve for future use" Voting (3. Votingblock im scalar rfc) so knapp ist. Ohne Zustimmung dazu oder einem anderen Vorschlag vor März/Mai kommen scalar typehints wohl nicht vor PHP8.

[SirSnyder]

Was spräche denn gegen:

function foo($a, (int)$b, int $c); 

Wer nicht typisieren will, der lässt es. Ist derzeit bei Objekten und Arrays nicht anders. Mit den optionalen weak Type Hints "(int)" definiere ich als Entwickler den gewünschten Typ und php kann schauen was da kommt und ggf. rumcasten wie es jetzt der Fall ist. Mit den optionalen strict Type Hints "int" verlange ich als Entwickler, dass der Wert so kommt.

Dieses Vorgehen fügt sich in die bestehenden Type Hints ein und jeder Entwickler kann es halten wie er möchte.

[tr0y]

Also gemessen an den aktuellen Votes geht das per 2/3-Mehrheit nicht durch.

[fireweasel]

Das ist ein schlechter Kompromiss. Was als Begründung für diesen Ansatz angegeben wird ist eigentlich fast alles irrelevant.

"Inkonsistens von PHP?"
PHP konsistent?

*rofl*

Das einzige was von diesen Argumenten in meinen Augen relevant ist, ist: "People who do not like weak or strict type checking would be forced to deal with strictly or weakly type-checked libraries, respectively."

Das verstehe ich nicht.

Wer Funktionen schreibt, kann die Parameter weiterhin so "weak" gestalten, wie er|sie will. Man kann ja die Typehints weglassen wie bisher.

Wer Funktionen benutzt, die "typehinted" sind, muss ihre APIs kennen. Dazu gehören auch die "Typen" der übergebenen Argumente. Das ändert sich nicht dadurch, dass man jetzt auch "Skalare" hinzufügt. Als "Callable" hinzukam, hat sich auch keiner beschwert.

und dann stehste plöztlich da und machst

$value = (float)($eingabe/10);
echo mache_aus_zahl_schoenen_preis($value); 

Das ist hier aber das Problem des Divisions-Operators: Mal bekommt man das Ergebnis als Integer und mal als Float zurück. Siehe deine obige Anmerkung zu PHP und Konsistenz. In anderen Sprachen gibts Integer- und Float-Division als getrennte Operationen.

Wenn man grundsätzlich das Ergebnis einer Division zu dem Typ casted, in dem man das Ergebnis haben möchte, dann besteht im folgenden Code keine Unsicherheit mehr darüber, womit man es denn zu tun hat.

Natürlich bleibt dabei die Frage ob das jemals zu einem wirklichen Problem wird. Spaltet sich dadurch die Community auf in strict und weak Libs oder regelt sich das von allein?

Wer Sprachen mit vernünftigem Typsystem mag, wird langfristig nicht mit PHP arbeiten.

[bwoebi]

Hmh, als jemand der selber dort abgestimmt hat…

Für mich ist es primär mal ein schlechter Kompromiss.
Und generell, kann ich mir striktes Typehinting nicht vorstellen: Jo, ich habe 'n Integer und wenn ich den jetzt einer mathematischen Funktion übergeben will, muss ich sowas jedes Mal casten? Nein, danke.
Und ein logischer Schritt wäre danach wohl noch überladen, damit wäre es wieder sinnvoll, aber bei declare(strict_types=0) könnte man davon auch nicht profitieren, da eine weak-types Implementierung überhaupt nicht wüsste was es aufrufen sollte.

Auch sind es so Kleinigkeiten wie, dass dann jede Datei ein explizites declare() oben hat, man keine Library mehr durchsehen kann ohne komplett konfus zu sein was für dein strict_type-Modus denn jetzt wieder benutzt wurde.

Generell bin ich ein Befürworter von weak Typehints, überall. (Warum ich gegen strict types bin, naja… PHP ist für mich eine Sprache, wo sich der Typ einer Variable letztendlich aus dem Wert ableitet (bspw. ein String "3" in einer mathematischen Operation). Das einzige was mir da manchmal Kopfzerbrechen bereitet sind implizite string-zu-double Umwandlungen wie "0e1" == "0x0" und bitweise Operationen auf numerischen Variablen, die davon abhängen ob mindestens einer der Operanden kein String ist...)

Für mich ist das ganze halt ein bisschen eine Wischiwaschilösung um typehints irgendwie in die Sprache zu drücken. (Das ist mMn auch warum viele mit Ja abstimmten: endlich Typehints!)

[SirSnyder]

Und generell, kann ich mir striktes Typehinting nicht vorstellen: Jo, ich habe 'n Integer und wenn ich den jetzt einer mathematischen Funktion übergeben will, muss ich sowas jedes Mal casten? Nein, danke.

Was spricht in dem Fall gegen ein "(float)" als TypeHint? PHP den Wert, wenn es möglich ist, zu float casten lassen. Wer keine TypeHints mag, muss sie nicht nutzen. So war es schon immer. Diese Freiheit sehe und schätze ich an PHP. Das declare ist einfach hässlich.

[tr0y]

casts haben in typeshints nix zu suchen, eher:

declare(strict_types=1,auto_cast=1); 

Was definitiv aber Seiteneffekte haben wird und im Endeffekt nur code cast-code spart.

[SirSnyder]

TypeHints sind Hints, nur Hinweise was da erwartet wird. Es ist keine Typisierung im Sinne von java und co und erst recht nicht strikt. Daher sehe ich an der Stelle die Möglichkeit zu casten, nicht so streng.

[bwoebi]

Ich meinte halt im Falle von strikten Typehints. Dann sinds auch keine Hints mehr, sondern halt Forderungen, wenn die aufzurufende Funktion das halt so verlangt. Das würde mich stören, da immer casten zu müssen.
Und auto_cast führt strict_types eh wieder ad absurdum… Dann sind es eigentlich auch nur weak hints…

[SirSnyder]

Hm, und was stört dich an strikten Hints, die jeder nutzen kann, wenn er es für angebracht hält oder die Situation es erfordert? Ich versuche da einen Einblick zu bekommen und dich/euch zu verstehen, man hat ja nicht jeden Tag die Möglichkeit mit einem PHP CoreDev zu schreiben

Ich arbeite gerade an einer sehr mächtigen Bibliothek und intern würde ich, wenn möglich, strikte TypeHints verwenden. Alles was öffentlich ist, bekäme schwache TypeHints.

[bwoebi]

Erstmal… wie willst du jetzt spezifizieren ob etwas strikt oder schwach typisiert sein soll? Mit dem RFC hier bestimmt das der Aufrufer, nicht der aufgerufene. Und dann gilt es auch halt für die ganze Datei. Du kannst nicht sagen: die built-in Funktionen von PHP sollen schwach typisiert aufgerufen werden, mir gefällt die starke Typisierung von der Bibliothek da nicht, ich möchte lieber die schwach typisiert aufrufen und intern dann aber stark typisieren.

Und ganz generell passt es auch nicht zu PHP. (Also bei nur strikt). Dann wären die internen Funktionen (Abwärtskompabilität und so) ja immer noch schwach typisiert und der Rest stark. Das ist auch wieder so ein Durcheinander...

Eine einheitliche (schwache) Typisierung in ganz PHP würde das Problem mMn einfach lösen können. Allerdings muss ich dazu sagen, dass die schwache Typisierung von PHP mir auch nicht wirklich 100%ig gefällt (ja, wir kennen alle das… ein nicht-numerischer string wird zu 0 gecastet wenn int verlangt wird (bei den internen Funktionen, zpp-style genannt)...). Meiner Meinung nach sollte zpp-Style ein bisschen strikter werden und dafür halt schwache Typisierung eingeführt werden.