nicht angemeldet
Tach!
Bei Primitiven (Skalaren) ist es nicht besonders sinnvoll, wegen der automatischen Typumwandlung. Auch Arrays wurden erst nachträglich hinzugefügt. Resourcen und Traits können ebenfalls nicht verwendet werden.
Man kann in PHP ja auch nach Typ prüfen (=== und Konsorten).
Damit kann man neben der Werte(un)gleichheit explizit _auch_ auf Typ(un)gleichheit prüfen, ohne dass eine automatische Umwandlung stattfindet, ja ...
Die automatische Typumwandlung könnte man also aussen vor lassen.
... die Frage ist allerdings, wie PHP bei Funktionsaufrufen damit umgehen soll und was die Antwort auf die 80/20-Frage ist. Was wollen 80% der Anwender? Soll das Argument getypecastet werden, wenn es nicht dem geforderten Typ entspricht? Oder soll PHP mehr in Richtung typsicherer Sprache mutieren, indem es an der Stelle falsche Typen abweist? Bei Klassen und Interfaces kann man noch damit argumentieren, dass der Typehint aufgrund der Individualität der Klassen/Interfaces sehr sinnvoll ist. Hier muss man dem Ruf nach einigermaßen verwendbaren OOP Gehör schenken. Aber bei den Primitiven sollte man der Natur PHPs ihren Lauf lassen und automatisch umwandeln. Spätestens im Body der Funktion/Methode schlägt ja dann doch wieder der Automatismus zu.
Der Codingstandard ist kein Gesetz. Es bleibt sinnlos, auch wenn es nun einheitlich aussieht. Aber welchen Nutzen hat das?
Ich würde an der Stelle dem Argument "auch wenn es nun einheitlich aussieht" gar nicht mal so wenig Bedeutung schenken und kann Sven seinen Einwand deshalb auch gut nachvollziehen. Übersichtlichkeit und Vereinheitlichung sollte man nicht unterbewerten.
Damit ist man zwar PHP-intern einheitlich, aber unterschiedlich zu zum Beispiel C#, bei dem das nicht gestattet ist. Das ist besonders für Wandler zwischen den Welten ärgerlich. Als nächtes könnte man noch auf die Idee kommen, Blocksatz wegen des einheitlichen rechten und linken Randes zu fordern ... Sinnlose Forderungen kann man ruhig als solche brandmarken und muss sie sich nicht schönreden.
dedlfix.