einfach nur crack hat gesagt.:
Nebenbei: Nennt man so einen Missbrauch nicht für gewöhnlich "Hack"?
Ja, das ist leider ein Hack. Ich rate deshalb davon ab, den Code zu nutzen. Das soll aber überhaupt nicht heißen, dass das nicht gut programmiert ist oder so. Ein Bier gebe ich dir dafür gerne aus, falls ich dich mal treffe. Das ist definitiv kreativ.
Einige Probleme:
- Ich halte es nicht für sinnvoll, eine Anwendung darauf aufzubauen, interne PHP-Fehlermeldungen zu parsen. Das ist in meinen Augen nicht robust oder zukunftssicher.
- Sobald Namespaces im Spiel sind, muss es use int; oder function f(\int $i) { /* ... */ } heißen (der reguläre Ausdruck des Parsers muss entsprechend erweitert werden). Das sind eben keine Schlüsselwörter, es sind tatsächlich Klassen im globalen Namensraum, die nach den Regeln spielen müssen.
- Passend dazu: Sollten die PHP-Entwickler wirklich mal int und so als Schlüsselwörter einführen, zerbricht das einen mehr oder weniger großen Teil des Codes (indirekt vermutlich allen), der den hier vorgestellten Ansatz nutzt. Anders gesagt: Jeder, der diesen Ansatz nutzt, gibt den PHP-Entwicklern leider einen Grund, besagte Schlüsselwörter nicht hinzuzufügen (Abwärtskompatibilität). Auch ist es nur Spekulation, dass die Datentypen aus diesem Projekt und die Datentypen, die PHP vielleicht mal erhalten könnte, inhaltlich deckungsgleich wären.
- Es wird schwierig bis unmöglich, bestimmte andere Error-Handler zu setzen als den, den dieses Projekt benötigt. Error-Handler sind eben dummerweise global. Verdeutlichung dazu: Sobald eine andere Library auch diese Feature nutzt, gibt es hässliche Zuständigkeitskonflikte, die womöglich nur lösbar sind, indem permanent die Handler vertauscht werden. Das ist in PHP aber ein allgemeines Problem, das an zig Stellen besteht.
- Da die Klassen nur virtuell sind, verstehen IDEs und sonstige Tools das womöglich nicht.
Die Gewichtung dieser Einwände ist schon irgendwie Ermessenssache. Es ist natürlich auch möglich, das einfach nur für PHP 5.5 zu entwickeln. Dort lässt sich das ja wie vorgesehen nutzen.
Es ist nur leider so, dass es sich dabei thematisch um eine sehr grundlegende Geschichte handelt, die weitere Programmierung in hohem Maße beeinflusst. (Das ist wohl tatsächlich auch ein Grund, warum sich die Core-Leute damit so schwer tun.) Wenn ich mir durch dieses Projekt sicher sein kann, dass ein Parameter nur einen Integer (wie auch immer der genau definiert ist) enthalten kann, muss ich das in einer Funktion zum Beispiel nicht mehr testen und dergleichen. Ich kann den Code in der Funktion dann also auf eine bestimmte Weise schreiben.
Wenn dann aber wirklich mal entsprechende Schlüsselwörter in den Core kommen oder wenn irgendein Hack-Gedöns (das Facebook-Zeugs jetzt) übernommen wird, dann ist die Art und Weise, auf die ich meine Funktionen programmiert habe, vermutlich nicht mehr kompatibel. Dann muss ein großer Teil des Codes überarbeitet werden.
Das sind die Probleme mit den Hacks. Hacks sind nicht normativ, wodurch immer die Gefahr besteht, dass sie sich außerhalb dessen bewegen, was die Sprachdesigner möglicherweise im Sinn haben. Es ist leider nahezu unmöglich, das irgendwie sinnvoll zu kalkulieren.
Das ist alles… *seufz* ärgerlich. Ich schätze, solange niemand von der Größenordnung von hacklang das Zepter da mal wirklich in die Hand nimmt und die Infrastruktur umkrempelt, wird es keine befriedigenden Lösungen geben.
![[PHP] Type-Hinting für elementare Datentypen](/data/resource_icons/0/60.jpg?1401014215){kind=icon}
Ehrlich gesagt kann mich gerade nicht dazu bewegen, dies in Angriff zu nehmen (ein wenig "kritisieren, aber selbst nichts machen"-Attitüde) 
