Tutti sanno che PHP ha problemi con Unicode. La versione 6 viene effettivamente abbandonata, a causa delle difficoltà di implementazione Unicode. Ma mi chiedo se qualcuno sa quali sono i motivi esatti ? Problemi di architettura / design, problemi di prestazioni, problemi di comunità (non scommetto), qualcos'altro?
Risposte:
PHP come lingua sicuramente può averlo, ma penso che il problema sia con la compatibilità con i programmi esistenti. Il supporto Unicode può romperli in modi sottili, che è il tipo di bug più fastidioso da avere.
Attualmente la maggior parte delle funzioni di elaborazione delle stringhe in PHP sono "binary-safe", il che significa che è possibile utilizzarle per elaborare qualsiasi file in qualsiasi codifica, nonché formati binari come dati di immagini, ecc.
Con l'aggiunta delle stringhe Unicode dovresti stare molto attento a non mescolare le stringhe Unicode con stringhe binarie (piuttosto difficile quando le tue stringhe provengono da fonti diverse e non ti devi mai preoccupare prima). E non potresti più ignorare le codifiche (e molti script lo ignorano!)
Un altro problema difficile ma risolvibile è l'accesso casuale nelle stringhe Unicode. Implementazione di $string[$offset]cambiamenti da banali a molto lenti o poco lenti e molto complessi.
Inoltre penso che sia stato un errore scegliere UTF-16 come codifica interna per PHP. Ha gli stessi problemi di UTF-8 (larghezza variabile a causa di coppie surrogate) e inefficienza di UCS-2. Forse dovrebbero scartarlo e ricominciare con UTF-8?
</speculation>
TLDR: molte librerie PHP sono solo un sottile strato rispetto alle librerie C native che non supportano Unicode o lo supportano in modi incompatibili tra loro. La correzione di questa situazione potrebbe introdurre cambiamenti incompatibili all'indietro.
NOTA BENE: dato che sono passato da PHP a Python (per non guardare mai indietro) qualche anno fa, la mia opinione è chiaramente distorta.
Penso che PHP sia un trucco carino e intelligente. Come un trucco, è iniziato senza pretese ed è cresciuto in qualche modo caotico da un mucchio di librerie sparse - privo di un design ben ponderato e unificato (dal punto di vista della teoria del linguaggio del computer).
Come detto da Machiavelli, "colui che non ha prima gettato le sue basi potrebbe essere in grado di posarle in seguito, ma saranno gettate con difficoltà all'architetto e pericolo per l'edificio".
Per un linguaggio di programmazione, il più popolare, il più difficile da cambiare. Ecco perché le lingue come C cambiano una volta ogni 10 anni. Ad esempio, Python 3 ha apportato molte modifiche incompatibili all'indietro e non è stato carino. Il supporto unicode nelle precedenti incarnazioni di Python era già considerato superiore allo stato attuale delle cose in PHP, ma indovinate un po ': i cambiamenti più polemici in Python 3 sono legati alla gestione degli unicode. Questo sfogo di Armin Ronacher riassume la frustrazione derivante da una grande parte della comunità di Python.
PHP essendo "la" piattaforma web onnipresente lo rende vittima del suo stesso successo. Portare un supporto unificato per Unicode in PHP è inevitabile, ma richiederà molto sangue, sudore e lacrime.
Uno dei motivi principali per cui il vecchio lavoro di PHP 6 è stato interrotto è stato dovuto alla complessità interna che ha portato e alla quantità di lavoro da svolgere, che a malapena nessuno ha completamente ignorato.
Un po 'di storia: l'implementazione Unicode di PHP 6 è stata progettata dalla necessità di un utente PHP più grande e ha provato a fare Unicode "giusto". Dopo alcune valutazioni, il progettista principale del supporto di essere Unicode di PHP ha scelto di aggiungere un nuovo tipo di stringa che è internamente Utf-16 e di consentire l'utilizzo di incisioni diverse in luoghi diversi. Quindi il codice potrebbe essere scritto in una codifica, l'output potrebbe usare una codifica diversa e "operazioni runtme" alcune altre codifiche. Il motivo della scelta di UTF-16 era che il lavoro doveva essere basato sul livrary ICU che utilizza UTF-16 e si è scoperto che questa codifica rende le operazioni di stringa comuni in modo rapido mentre la conversione tra utf- e utf-16 è relativamente economica . Fin qui tutto bene.
Ora la conseguenza di ciò è innanzitutto l'introduzione di un nuovo tipo di stringa. Il sistema di tipi interno di PHP fino ad allora aveva alcuni tipi (NULL, bool, int / long, float / double, stringa, array, risorsa, oggetto) e molti codici avevano alcune ipotesi su questo. Oltre a questi presupposti, tutte le funzioni che operano su stringhe, e ce ne sono molte, devono essere valutate individualmente e si deve decidere come gestire le codifiche. Dovrebbero funzionare su stringhe binarie o stringhe unicode? Se è richiesta una conversione quale codifica dovrebbe essere usata ecc. E questo è molto lavoro e in alcuni casi abbastanza complicato da fare nel modo giusto. Inoltre, le API interne sono diventate piuttosto complicate, poiché la maggior parte delle API chiave in PHP hanno versioni per stringhe binarie (quella precedente) e spesso una versione per stringhe "runtime coded",
Nel processo in cui molti sviluppatori si sono imbattuti nella coplexity, sono rimasti infastiditi da utf-16 e non gli piaceva il fatto che questo avrebbe più che raddoppiato l'uso della memoria e avrebbe speso molto tempo a convertire le stringhe rompendo la maggior parte delle applicazioni esistenti. Quindi, PHP guidato da volontari, sempre meno sviluppatori ci stavano lavorando e altre cose si sono accumulate e i partecipanti sono diventati infelici e alla fine hanno dovuto essere abbandonati.
Cosa potrebbe portare il futuro? - Sta accadendo una lenta evoluzione che sempre più cose in PHP sono state costruite intorno a utf-8. Non in modo forte con un tipo personalizzato e costringendo tutto e attualmente gli sviluppatori non sono motivati a toccare questo ferro caldo. Si può sperare che qualcuno abbia una buona proposta per farlo funzionare bene, ma attualmente "tutti" scapperanno se sentiranno solo la parola. :)
Immagino che il vero motivo sia che il team di sviluppo di PHP non ha una roadmap chiara per lo sviluppo di PHP (menzioniamo solo una discussione piuttosto accesa quando qualcuno sui php-internals ha deciso di avviare il ramo PHP 5.4 senza concordare in precedenza quali caratteristiche dovrebbero contenere 5.4). Mi piace molto questa lingua, ma il modo in cui viene sviluppata mi rende un po 'preoccupato.