Ne ho discusso tanto sul Blog di HTML.it, e probabilmente continuerò a farlo finché non succederà qualcosa che mi farà cambiare idea: PHP deve evolvere per restare al passo con la concorrenza. Il nostro amato linguaggio sta, da qualche anno, perdendo i colpi rispetto alle alternative che si fanno sempre più interessanti e riescono a ritagliarsi sempre più spazio tra gli sviluppatori web; siamo passati da un periodo in cui PHP la faceva da padrone incontrastato ad un periodo in cui sono venuti a galla una serie di strumenti e soluzioni (vedasi Ruby on Rails, cui HTML.it dedicherà una guida nelle prossime settimane, Zope, Django per citarne qualcuno) che stanno pian piano soppiantando il concorrente. Anche gli hoster si stanno adattando alla nuova tendenza, cercando di fornire il supporto per i linguaggi alternativi anche nelle soluzioni più economiche.
Questo calo di PHP (anche se non ampiamente evidente a chiunque) è da considerarsi conseguenza di alcune scelte implementative che hanno puntato allo stabilizzare soluzioni obsolete piuttosto che puntare all'innovazione ed alla sperimentazione. Sarà anche vero che una parte degli sviluppatori che stanno migrando ad altre piattaforme sia influenzata un po' dalla moda del momento, ma nessuno può mettere in dubbio che il programmatore medio necessità di un ambiente più stabile, sicuro e standard per poter lavorare.
Per risolvere alcuni di questi problemi gli sviluppatori di PHP stanno lavorando ad una nuova major release chiamata PHP 6, che colmerà gran parte dei buchi lasciati da PHP 5 e fornirà agli sviluppatori un nuovo ambiente ed una nuova filosofia di programmazione, cercando di allontanare definitivamente gli sviluppatori dall'era di PHP 4 (che per molti motivi regna ancora incontrastato, soprattutto nelle piccole realtà).
In questo articolo mi occuperò di introdurvi ad alcune delle funzionalità pianificate, ricordandovi che su snaps.php.net è possibile recuperare i sorgenti per iniziare i primi test con il nuovo linguaggio.
Il supporto per Unicode
Oggi non concepisco un linguaggio senza il supporto nativo per Unicode. Come già ampiamente discusso sul Blog e su alcuni articoli precedenti, Unicode è un sistema di codifica standard che assegna una combinazione di bit ad ogni carattere in maniera indipendente dalla piattaforma, dal programma e dalla lingua utilizzate; si basa sulla codifica ASCII estesa, codificando però una quantità enorme di caratteri, sia di lingue vive che morte, nonché simboli matematici, chimici, cartografici, l'alfabeto Braille e molto altro. Da anni Unicode è supportato da tutti i sistemi operativi, per i quali ormai è diventato la base su cui costruire l'intero sistema. L'affermarsi di questa tecnologia è conseguenza del fatto che ormai i programmi devono poter essere globalmente fruibili indipendentemente dalla lingua e dell'alfabeto utilizzati.
A fronte di questo, molti linguaggi si sono attrezzati fornendo a volte librerie di supporto ed altre volte soluzioni native. PHP fa parte del primo gruppo, anche se fino ad ora (versione 5.x) le librerie fornite per la gestione dei caratteri multibyte e delle codifiche non sono considerabili standard e non sono per nulla integrate con l'ambiente.
PHP 6 cerca di risolvere questo grosso problema modificando interamente il proprio sistema di gestione stringhe ed aggiornandolo ad una versione più potente che supporta la codifica Unicode; verranno anche automaticamente codificati i dati in input ed output in modo da assicurarsi che i sistemi con cui il linguaggio comunica ricevano i caratteri nella codifica necessaria senza la necessità di effettuare manualmente la conversione. Quindi avremo solamente due tipologie di stringa: quella binaria e quella non, e la codifica utilizzata dall'ultima potrà essere controllata a runtime in modo da poter passare da Unicode al altre alternative implementate. Attualmente il sistema di gestione delle stringhe è un po' più lento del previsto e gli sviluppatori stanno lavorando assiduamente per poter portare le performance ad un livello accettabile per il numero di caratteristiche introdotte.
Pulizia delle funzionalità
Ne parlavo anche sul Blog e qui mi voglio ripetere: PHP esiste da moltissimo tempo ed è stato utilizzato ed aggiornato moltissime volte, spesso per venire incontro alle esigenze pressanti degli sviluppatori o ai bug consistenti del sistema. Tutto questo, nonché la volontà di includere nella distribuzione standard una serie di librerie senza utilizzare delle linee guida per la stesura del codice (o per lo meno delle API pubbliche), ha portato ad una serie di cattive abitudini che ormai la maggior parte degli sviluppatori PHP sta cercando di rimuovere. Le cattive abitudini portano spesso a dei grossi bug nelle proprie applicazioni oppure a script molto lenti che consumano un numero eccessivo di risorse.
Purtroppo questa serie di cattive abitudini non sono sempre causate dalle scelte dello sviluppatore, ma spesso (soprattutto nelle versioni meno recenti di PHP) sono conseguenza di alcune funzionalità di configurazione di PHP che il programmatore (spesso involontariamente o senza conoscere le reali problematiche riscontrabili) si ritrova ad utilizzare nelle proprie applicazioni. Tra queste funzionalità le più pericolose sono sicuramente le direttive register_globals, magic_quotes e safe_mode del file php.ini; in mano a mani inesperte (come spesso purtroppo accade) posso creare seri problemi di sicurezza e performance. Per rimuovere alla radice il problema le funzionalità verranno rimosse, generando un errore quando verrà rilevata la direttiva all'interno del file php.ini.
Anche il supporto per la prima versione dello Zend Engine verrà rimosso, rendendo obsolete (e segnalate da un errore) i riferimenti espliciti ed il supporto per le classi in vecchio stile. Verranno comunque mantenuti il supporto ai costruttori vecchio stile (quelli rappresentati da un metodo con il nome della classe che devono andare a generare) ed a var (che funzionerà come alias di public). Infine verranno rimosse le vecchie versioni di alcune librerie tra cui FreeType 1 e GD 1 e verrà notevolmente migliorato il supporto a FastCGI ed il controllo sulla direttiva dl().
Queste scelte porteranno sicuramente ad una diminuzione della compatibilità degli script e delle applicazioni, ma nel caso una soluzione non risulti compatibile con le nuove politiche vorrà dire che è bene che venga aggiornata, sia per motivi di sicurezza sia per il fatto che la manutenzione dei programmi è un'operazione sacrosanta che andrebbe svolta abitualmente, indipendentemente dai cambiamenti del linguaggio utilizzato.
Le librerie standard
Dopo lunghe discussioni e dibattiti, gli sviluppatori di PHP hanno deciso di lavorare anche sulle librerie distribuite con la versione standard di PHP, aggiungendone di nuove, rimuovendo quelle obsolete e soprattutto spostando quelle poco utilizzate o deprecate al repository PECL. La scelta è dovuta al fatto che troppo spesso (soprattutto per problemi di compatibilità) vengono utilizzate vecchie versioni delle librerie oppure le nuove soluzioni proposte, sempre più sicure e performanti, non vengono prese in considerazione per i nuovi prodotti sviluppati. In questo modo l'obiettivo del team di PHP è quello di spingere il programmatore verso l'utilizzo di sistemi avanzati e sicuri come PDO ed SDO, lasciando da parte le vecchie librerie specifiche per l'accesso ai database. Oltre a rendere più agevole e standard lo sviluppo con i database, verrà spostato su PECL il supporto per la sintassi EREG delle espressioni regolari, rendendo di fatto standard e non più disabilitabile l'implementazione PCRE.
Alla distribuzione verranno aggiunte due librerie per la gestione dell'XML: XMLReader (basato su SAX ma con un'interfaccia più adatta alla programmazione nel nuovo ambiente) ed XMLWriter.
Ultimo ma non per questo meno importante, sarà l'integrazione nativa dalla libreria APC in PHP. APC (Advanced PHP Cache) è una libreria che si occupa di ottimizzare ed effettuare il caching in memoria del bytecode degli script al fine di ottimizzare notevolmente le performance del sistema, rimuovendo il collo di bottiglia dovuto al parsing ed all'analisi dell'albero sintattico effettuata attualmente dal linguaggio ogni volta che un file viene richiesto.
Aggiunte all'engine
Ovviamente non potevano mancare dei miglioramenti al modello ad oggetti già ampiamente ridisegnato e migliorato nella versione 5 di PHP ed alcune aggiunte allo Zend Engine. In primo luogo probabilmente verranno reintrodotti i namespace, che erano stati rimossi da PHP 5 perché non risultavano compatibili con le necessità di retrocompatibilità del sistema.
I namespace sono un sistema che permette di raggruppare variabili, classi e funzioni all'interno di un determinato spazio dei nomi, al fine da diminuire le possibilità di collisione e ridefinizione dei nomi. In questo modo, includendo le nostre librerie in un namespace univoco (come ad esempio il nome della nostra applicazione) ed utilizzandolo esplicitamente potremo essere sicuri di limitare problemi di compatibilità con altre soluzioni fornite da altri sviluppatori o ambienti di sviluppo.
Conclusioni
Come al solito sono giunto alla fine dell'articolo senza accorgermene. Ovviamente trattare in modo approfondito tutte le caratteristiche di PHP 6 sarebbe un'operazione lunga e forse prematura; vi rimando comunque, per chi ne fosse interessato, al resoconto del meeting dell'11 novembre 2005 a Parigi.
