PHP: Nullable Types und "iterable" pseudo-type

[Sven Rautenberg]

Moin!

Das sind keine aktuellen News, aber ich habe es erst jetzt durch einen Zufall erfahren. Die PHP-Entwickler haben sich gegen ein Proposal entschieden, das das Typsystem um Union-Types erweitern wollte. Kurzum handelt es sich dabei um eine Möglichkeit, neue Typen durch die Veroderung bereits bekannter Typen einzuführen. Damit dürfte auch das Schicksal des Proposals für Intersection-Types (eine Und-Verknüpfung auf Typen) besiegelt sein.

Sicherlich nicht. Proposals scheitern oder sind erfolgreich je nachdem, wie gut sie vorbereitet sind und natürlich auch, inwieweit sie Weitsicht in Bezug auf mögliche Seiteneffekte zeigen.

Dieses Proposal hat sich vor allem in den Beispielen NUR mit der Möglichkeit von Skalartypen beschäftigt, also mit einer Konkretisierung von "mixed".

Was ist mit Klassen? Könnte ich als Parameter einer Funktion vielleicht eine von zwei unterschiedlichen Klassen hineingeben? Wie sollte sowas praktisch funktionieren? Und was sagt das über die Codebasis aus? Denn normalerweise wäre in solchen Fällen ein Interface oder eine abstrakte Basisklasse angesagt.

Die Proposals waren nach meiner bescheidenen Einschätzung eine erstklassige Gelegenheit sich aus dem konservativen C/Java-Lager zu verabschieden und zu modernen highlevel Sprachen aufzuschließen. Die Entscheidung überrascht mich um so mehr, da man sich damit auch von dem PHP-Ableger Hack weiter distanziert.

Es gibt das Proposal für Nullable Types: https://wiki.php.net/rfc/nullable_types - erfolgreich angenommen.
Außerdem gibts das Proposal für Iterable: https://wiki.php.net/rfc/iterable - ebenfalls erfolgreich angenommen.

Somit sind zwei Vorschläge mit sehr konkretem Scope in der Implementierung für PHP 7.1, die sich mit den real auftretenden Einschränkungen der bisherigen Sprache beschäftigen:

1. Das Problem der Übergabe oder Rückgabe von "nichts" war bislang für die Übergabe nur mit einem Default-Wert "null" zu lösen, für die Rückgabe gar nicht.
2. Das Problem der Übergabe von nativen Arrays oder alternativ Traversable-implementierenden Objekten war bislang nur komplett ohne Typehint lösbar und hat entsprechende Fehlerbehandlung im Code erforderlich gemacht.

Grüße Sven