Nei precedenti capitoli abbiamo visto le principali funzioni legate al linguaggio per la creazione delle nostre pagine dinamiche. La differenza fra quelle funzioni e la famiglia di quelle che andremo a vedere è sostanziale: le prime sono presenti direttamente all'interno del motore (built-in), le seconde sono presenti in librerie aggiuntive che devono essere installate sul sistema e richiamate in maniera particolare.
Prima di tutto, vediamo di capire il meccanismo di caricamento dinamico di queste librerie: aprendo il file php.ini vedremo un paragrafo dedicato alle "Extension", ossia estensioni nel linguaggio stesso: per spiegarci meglio, potremo dire che queste sono un insieme di librerie che vengono richiamate al momento dell'esecuzione di uno script come avviene, in maniera analoga, per il caricamento dei moduli con un webserver.
La sintassi per il caricamento di queste estensioni di linguaggio è molto semplice: una volta che avremo installato la libreria sul sistema, non ci resta che aggiungere nel file php.ini la riga:
extension=libreria
È qui necessario un discorso mirato per i sistemi Unix ed i sistemi Windows: per entrambi la sintassi è identica, ma ovviamente il nome delle librerie e la loro estensione no.
Nei sistemi Windows, una libreria si riconosce dall'estensione ".dll", mentre per Unix questa è ".so": quindi, a seconda del sistema, dovremo utilizzare il corretto nome per la libreria e, soprattutto, la corretta estensione. Ovviamente, per chi abbia entrambi i sistemi installati e riesca da uno dei sistemi a vedere l'altro è chiaro che le dll non possono essere caricate su un sistema Unix e viceversa.
Nello scrivere il nome della libreria che ci interessa caricare, non dobbiamo soffermarci sul percorso completo, ma è necessario solamente il nome della stessa, ad esempio pgsql.so per i database Postgres. Questo perchè, nello stesso file, è presente un'altra linea di configurazione che definisce in quale directory sono presenti queste librerie: leggendo il file php.ini potrete trovare la riga extension_dir = directory che istruirà il motore sulla locazione standard delle librerie. Quindi, quando specifichiamo con extension una libreria che vogliamo sia caricata per l'esecuzione di uno script, vengono di fatto uniti extension_dir ed extension: se ad esempio extension_dir è /usr/lib/php e abbiamo impostato extension=pgsql.so, il PHP saprà che per caricare la libreria pgsql.so dovrà cercarla in /usr/lib/php/pgsql.so.
Inoltre, con l'istruzione extension= .... è possibile specificare non solo una libreria ma tutta la seri di librerie che ci possono fare comodo: ad esempio possiamo avere qualcosa del tipo:
extension=pgsql.so
extension=mysql.so
extension=gd.so
extension=imap.so
extension=ldap.do
extension=xml.so
e via dicendo; come noterete dalla seconda riga, poi, è possibile specificare anche due o più librerie per uno stesso "campo" in questo caso, ci sono due librerie per due database (Postgres e MySQL) che, oltre a non entrare in conflitto l'una con l'altra, potrebbero teoricamente anche essere utilizzate contemporaneamente, a patto che questo abbia un'utilità.
Nel caso si cerchi di richiamare una funzione non built-in all'interno di uno script, lo script visualizza una messaggio d'errore che ci avverte che stiamo cercando di utilizzare una funzione non riconosciuta: ad esempio, per i database, devono essere caricate le estensioni come detto prima e, solo dopo aver compiuto questo passo, sarà possibile utilizzare le funzioni ad essi relativi senza incorrere in messaggi d'errore, sempre che queste siano utilizzate in maniera corretta, ovviamente.
Il perchè delle estensioni
A questo punto, ci sarà sicuramente chi si chiederà il perchè di questa librerie aggiuntive (a volte molto importanti o addirittura essenziali) che devono essere scaricate, installate e richiamate indirettamente. La spiegazione è semplice: per non appesantire inutilmente il motore. Di per sè questo ha già un grande numero di funzioni built-in, che potremo definire le funzioni "principali" per il linguaggio, sebbene alcune possano sembrare di poca utilità. Immaginate ora che il motore avesse al suo interno anche tutte le funzioni relative a tutti i database che supporta: avrebbe un altro centinaio (abbondante) di funzioni al suo interno; e questo non sarebbe un male se il 95% di queste non fosse inutilizzato.
Chi, infatti, ha la necessità di lavorare con il PHP ed una decina di database differenti? È sicuramente meglio installare l'estensione per il database che si deve utilizzare e non appesantire il motore con funzioni che certamente non utilizzeremo mai. Inoltre, pensate anche alle funzioni della libreria GD: senza dubbio sono interessanti per i risultati che permettono di ottenere, ma quanti in realtà le utilizzano? È più semplice fornire tutte queste funzioni in un file separato e lasciare che questo venga installato ed utilizzato da chi ne ha veramente bisogno.
Se ci pensate, è quello che avviene per tutti i linguaggi di programmazione: esistono le primitive (che, in linea di massima, possiamo definire come le funzioni essenziali e built-in in un sistema) e le funzioni in qualche modo esterne che vengono richiamate all'occorrenza. Rimanendo nei linguaggi di scripting, un paragone può essere fatto ad esempio con il Perl: anch'esso ha una nutrita schiera di funzioni built-in nell'interprete, alle quali si aggiungono la quasi infinità di moduli che il programmatore può utilizzare all'interno delle proprie creazioni.