Moin molily,
Aber dieses Verhalten Copy-on-Write soll ja abgeschafft werden.
Aha. Du meinst der PHP-Interpreter wird sein Verhalten ändern bzw. auf Copy-on-Write zu vertrauen ist schlechter Stil?
Das war immer schon schlechter Stil. Copy-on-write ist implementation specific, der Zend-Interpreter nutzt diese Technik als Performance-Optimierung. Und die Umstände, unter denen diese Optimierung verwendet wird, ist auch nicht immer sofort einsichtig. Die HHVM z.B. verwendet intern immutable strings mit Copy-On-Write-Mechanismus (schreibt man das so? sieht scheiße aus…), aber wenn der refcount (HHVMs GC funktioniert über refcounting) exakt 1 ist, dann wird der String doch in-place geändert.
Implizite Referenzen gibt es nur bei Objekten, alles andere muss explizit referenziert werden.
Müsste man dann in Zukunft explizit eine Referenz anlegen, sonst würde sofort kopiert?
Relevant ist diese Überlegung nur für Strings, Arrays/Hashes und Objekte, alle anderen Datentypen sind trivial zu kopieren, da würde das copy-on-write mehr Performance fressen als gewinnen (ein int z.B. ist 4 bzw. 8 Byte gross, also Word-Größe, zzgl Meta-Informationen, die aber sowieso gespeichert werden müssen – da macht copy-on-write einfach keinen Sinn). Bei Objekten wird von Haus aus mit Referenzen gearbeitet. Strings sind in PHP immutable, das bedeutet, dass hier keine Kopie angelegt werden muss. Bei den üblichen String-Operationen (z.B. concatenation) wird ein neuer String erstellt (Ausnahmen siehe oben). Bleiben Arrays/Hashes übrig.
Ein Grund, den ich mir vorstellen kann, warum man darauf verzichten wollen würde, wäre Threading. Es ist durchaus problematisch eine Kopie zu einem späteren Zeitpunkt anzulegen, in einer Multi-Threaded-Umgebung kann man ja nicht sicher sein, dass die Daten in der Zwischenzeit nicht geändert werden.
LG,
CK