Oooh ja, deshalb wahrscheinlich auch die Diskussion.
ComFreek hat gesagt.:
[Zur Vermeidung inkonsistenter Zustände bei plötzlichen Fehlern] gibt es verschiedene Gegen-/Vorsichtsmaßnahmen
Ja, mir ging es bei dem Beispiel darum, zu zeigen, dass man nicht einfach sagen kann, dass es das implizite Type-Casting von PHP schon richten wird. Es gibt eben Fälle, in denen falsche Datentypen reingereicht werden können, die dann irgendwann später zu Fehlern führen. Das sollte zeigen, dass man sich als PHP-Entwickler mit Type-Hinting beziehungsweise mit korrekten Datentypen befassen muss, ob man will oder nicht. Die Alternative wäre höchstens, zu sagen, dass die Funktion schon niemand falsch aufrufen wird. So möchte ich aber ungern Code schreiben, zumal entsprechende Checks auf korrekte Datentypen ja relativ simpel möglich sind. Es ist bloß Schreibarbeit, wenn man wirklich immer von Hand
if (!is_string($param)) throw new Exception(); tippt. Mit den entsprechenden Ansätzen hier geht es ja darum, diese Schreibarbeit zu reduzieren. Letztlich sollte das aber optimalerweise die PHP-Engine automatisch übernehmen. Das ist zumindest ein Wunsch, den viele Entwickler haben. Das ist historisch betrachtet nur nicht unbedingt die Philosophie von PHP.
Zu den zusammengesetzten Typen ("Compund-Typen")
Alternativen wären Overloading oder auch Konzepte, die manche Umwandlungen ohne explizites Anweisen zulassen (int nach float), die andere aber wegen potenziellem Datenverlust erst mal zurückweisen (float nach int). In Java etwa:
Code:
public class Foo
{
public static void main(String[] args)
{
int i = 10;
double d = i; // funktioniert
String s = "" + d; // funktioniert halb, das "" + ist im Grunde auch
// schon explizites Casting
double e = 10.5;
int j = e; // error: possible loss of precision
// Das wäre explizit etwa per int j = (int) e;
// möglich
}
}
Anders angefangen: Es braucht keinen Compound-Type „numeric“ (der jetzt der Einfachheit halber nur int und float umfasst), wenn bei einem float-Type-Hint ein int-Parameter automatisch nach float gecastet wird. So macht es wiederum Java:
Code:
public class Foo
{
public static void main(String[] args)
{
Foo app = new Foo();
int i = 10;
app.demo(i);
}
public void demo(double f)
{
System.out.println(f); // Gibt 10.0 aus (also Fließkomma), nicht 10 (int)
}
}
Dass in dem PHP-Compound-Type „numeric“ noch andere Datentypen (zumindest string) drinstecken, ist zusätzlich wirr. Das macht etwa Java nicht mit. Da geht es zum Beispiel so:
Code:
String s = "10";
app.demo(Double.parseDouble(s));
Oder alternativ per Overloading, wenn man drauf steht:
Code:
public class Foo
{
public static void main(String[] args)
{
Foo app = new Foo();
String s = "10";
app.demo(s);
}
public void demo(double f)
{
System.out.println(f);
}
public void demo(String s)
{
demo(Double.parseDouble(s));
}
}
Ich empfinde das als wesentlich sauberer und mag deshalb ein Konzept von einem „numeric“ als – zumindest – Pseudo-Datentyp nicht wirklich.
Dazu auch noch diese Seite, die einen ganz netten Einblick bietet, wie kompliziert so Datentypen und Umwandlungen sein können:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html Wenn es einfach wäre, hätte PHP das vermutlich wirklich schon lange. Man muss sich eben richtig in die Thematik einarbeiten und dann Lösungen finden, die in PHP – immerhin eine Interpretersprache, Kompilierung muss also schnell gehen – möglich und sinnvoll sind und zum Ökosystem (interne Funktionen, Extensions) passen.
Nun, was ich sagen möchte, ist, dass man als Programmierer einer Funktion/Bibliothek nicht immer jeden x-beliebigen Parameter prüfen sollte. Dies ist die Aufgabe des Callers. Durchläuft man alle Abstraktionsschichten kommt man irgendwann bei den Validierungsmaßnahmen von Nutzereingaben an. Und da sollten diese auch strikt sein!
Ja… Schwieriges Thema. Ich programmiere sehr komponentenorientiert, also ich organisiere Code sozusagen in Einheiten, die über so eine Art API miteinander verbunden sind. Bei den Einsprungspunkten der Komponenten, bei dem Code, der von anderen Komponenten aufgerufen wird, bin ich gerne strikt, was Eingaben angeht. Innerhalb der Komponenten validiere ich dann eigentlich nicht mehr. Das ist so die Idee, dass ich innerhalb der Komponente selbst dafür sorgen kann, dass ich die passenden Sachen übergebe, weil dort außer mir niemand rumzupfuschen hat.
Diese Sichtweise kann man natürlich beliebig „skalieren“. Man kann durchaus auch sagen, dass in einer Anwendung alles außer den Nutzereingaben sauber ist. Ich finde das daher schwierig pauschal zu diskutieren. Das sind Themen, die sehr weitläufig sind.
Übrigens gibt es bei der Programmiersprache Ada für Integers auch einen Range-Type, welcher Zuweisungen von Zahlen außerhalb des definierten Bereiches mit Exceptions quittiert
Auch das ist ein interessanter Aspekt, weil das demonstriert, dass selbst ein Type-Hint, der nur den passenden Datentyp durchlässt, noch nicht das Ende des syntaktisch Möglichen ist. Das zeigt auch, wie sehr das, was in Programmiersprachen in Syntax gegossen wird und was nicht, willkürliche Konvention ist. Syntax ist letztlich eben auch bloß eine Metapher zur schriftlichen Abbildung von Modellen oder von Realität. Uff.
einfach nur crack hat gesagt.:
Praktisch gesehen bin ich auch ein Freund der ensure-Variante oder der PHP-eigenen Filter-Funktionen.
Letztere sind leider grottig dokumentiert, finde ich.
Generell ist das fehlende (konsistente) Typehinting in PHP mein größtes Problem in PHP […] und es für mich ein "pain in the ass" […].
Ja.
![[PHP] Type-Hinting für elementare Datentypen](/data/resource_icons/0/60.jpg?1401014215){kind=icon}
