Die Abstimmung über das Deprecations-for-PHP-8.6-RFC ist durch, doch die Diskussion auf der Internals-Liste zeigt offene Fragen rund um die CSV-Verarbeitung in SPL.

Robert Humphries bringt zwei Einwände vor. Erstens nennt das RFC keinen Migrationspfad für bestehenden Code. Wer SplFileObject::fputcsv() nutzt, kann nicht einfach auf die prozedurale Funktion fputcsv() wechseln, denn diese erwartet eine Stream-Ressource und ist damit kein Drop-in-Ersatz.

Zweitens ist das Flag SplFileObject::READ_CSV nicht Teil der Deprecation. setCsvControl() ist der einzige Weg, um Delimiter, Enclosure und Escape-Zeichen für READ_CSV zu konfigurieren, der Konstruktor akzeptiert sie nicht. Verschwindet setCsvControl() in PHP 9, während READ_CSV bestehen bleibt, ist das Flag dauerhaft auf seine Defaults festgelegt und Tab-getrennte Dateien lassen sich darüber nicht mehr lesen. Der Standardwert von $escape ist zudem selbst bereits deprecated und soll sich ändern.

Humphries folgert: Entweder sollte READ_CSV zusammen mit den vier Methoden deprecated werden, oder setCsvControl() sollte erhalten bleiben, bis eine Ersatz-API existiert. Ein weiterer Beitrag merkt an, dass nach der bestandenen Abstimmung eine Deprecation von READ_CSV nötig erscheint. Andernfalls würde sich Code mit READ_CSV nach der Änderung des $escape-Defaults je nach PHP-Version unterschiedlich verhalten, ohne Möglichkeit zur manuellen Vereinheitlichung.