Latoserver.it/ PHP: verso Zend 2.0

Qualcosa di molto interessante bolle in pentola nel mondo del PHP: la nuova generazione di Zend, il motore alla base del linguaggio

Latoserver.it/ PHP: verso Zend 2.0Roma - Sebbene la popolarità del linguaggio PHP sia costantemente in aumento, non mancano le perplessità sulla effettiva proponibilità di PHP per lo sviluppo di applicazioni complesse. Molta strada è stata percorsa dai tempi di PHP/FI, con un salto di qualità addirittura epocale quale è stato il passaggio dalla versione 3 alla 4. È altrettanto indubbio, tuttavia, che c'è bisogno di proseguire nel miglioramento del linguaggio se si vuole evitare il rischio che rimanga relegato nel ruolo di "giocattolo" o poco più.

Fortunatamente qualcosa di molto interessante bolle in pentola: la nuova generazione di Zend, il "motore" alla base del linguaggio, che promette innovazioni significative rispetto alla situazione attuale.

Alcuni problemi attuali
Prima di anticipare le novità del nascituro Zend 2.0, soffermiamoci per un po' su quegli aspetti critici del linguaggio a cui si è accennato in precedenza.

Il primo è certamente il supporto limitato al paradigma object-oriented. Nonostante i miglioramenti introdotti in questa direzione da PHP4 (basato su Zend 1.0) rispetto alla precedente versione 3 (basata su Zend "0.5"), PHP rimane essenzialmente un linguaggio procedurale, con tutte le problematiche che ciò comporta. Scrivere codice PHP pulito (nel senso di scevro da "truccacci" di qualsivoglia genere) non è semplice; se poi si ambisce alla riusabilità del software diventa ancor più evidente che, pur adottando il massimo rigore, non si riesce ad andare oltre un livello di complessità medio-basso.

Un altro aspetto critico è quello della mutevolezza di alcune caratteristiche del linguaggio: si pensi, ad esempio, alla gestione delle cosiddette variabili esterne (ne abbiamo già parlato), modificata sensibilmente in almeno due occasioni. Questa particolare "instabilità", ulteriormente accentuata dal fatto che spessissimo cambiamenti anche di rilievo avvengono in occasione di minor release, se non verrà in qualche modo arginata, rischia di dar vita ad innumerevoli micro-versioni di PHP, sottilmente (e diabolicamente) incompatibili fra loro. Il rischio, insomma, è che quello che oggi è buon codice, divenga domani un lavoro da rifare, in tutto o in parte.

Le due limitazioni sopra menzionate richiedono ovviamente soluzioni diverse. Tuttavia mentre per quanto riguarda la seconda possiamo solo auspicare una stabilizzazione delle caratteristiche del linguaggio, per la prima ci sono buone notizie in arrivo. Possiamo, quindi, introdurre la prossima generazione di Zend, il motore del PHP che verrà.

Zend 2.0
La novità più importante di Zend 2.0 sarà il miglioramento del supporto per la programmazione object-oriented (OOP). Alla base delle nuove funzionalità, che verranno descritte nel resto dell'articolo, vi è una riprogettazione del modello ad oggetti usato da PHP fortemente influenzata dal linguaggio Java.

Il nuovo modello ad oggetti
Zend 2.0, in particolare, introduce la gestione degli oggetti (un oggetto, ricordiamo, è una istanza di una classe, una sua "incarnazione") tramite handles, degli identificatori assimilabili a puntatori. Nella serie 1.x di Zend, invece, gli oggetti vengono trattati come valori del linguaggio al pari di stringhe, interi, etc.

Le conseguenze immediate di questa novità sono notevoli. Assegnare ad una variabile un oggetto significherà copiare in essa l'handle che lo identifica e non copiare l'intera istanza. Analogamente in caso di passaggio di un oggetto come argomento di una funzione sarà il solo handle ad essere fornito alla funzione stessa, evitando così una duplicazione inutile e una potenziale fonte di bachi.

Fin qui si potrebbe avere l'impressione di non avere di fronte nulla di nuovo rispetto all'uso dei riferimenti (references) introdotti in PHP4. Risulta evidente il contrario se si considerano le possibilità inedite rese fattibili dal nuovo modello ad oggetti. Vediamone alcune.

Dereferenziazione. Il nuovo modello ad oggetti renderà possibili istruzioni del tipo $oggetto1->metodo1()->metodo2() dove metodo2() viene invocato rispetto all'oggetto restituito da metodo1(). Questa funzionalità, disponibile in molti linguaggi di programmazione, oltre ad essere di uso molto intuitivo, consente di scrivere codice più sintetico e previene alcuni tipi di errore.

Distruzione esplicita di oggetti. Mentre con l'attuale versione di Zend è impossibile deallocare un oggetto esplicitamente (la distruzione avviene automaticamente quando non vi sono più riferimenti ad esso), nel nuovo Zend ci sarà una funzione, delete(), che consentirà di distruggere un oggetto anche quando vi siano variabili che fanno riferimento ad esso.

Distruttori. Una classe potrà finalmente avere un distruttore, cioè un metodo che viene chiamato automaticamente prima della deallocazione di una istanza. Il metodo da usare come distruttore dovrà obbligatoriamente chiamarsi __destruct().

Le altre novità
Tra le novità di Zend 2 ve ne sono altre di grande interesse che non discendono dal nuovo modello ad oggetti.

La più rilevante è sicuramente la possibilità di gestire le eccezioni, in modo simile a quanto avviene in Java ed altri linguaggi. I costrutti sintattici sono i classici try, throw e catch. Il primo viene utilizzato per racchiudere un insieme di istruzioni considerate "a rischio di eccezione"; se in tale blocco viene sollevata, con il costrutto throw, una eccezione, questa viene intercettata e gestita dal blocco catch più vicino. Il meccanismo delle eccezioni risulta particolarmente conveniente in quanto solleva il programmatore dalla fastidiosa necessità di gestire le possibili situazioni di errore istruzione per istruzione.

Altre due novità che dovrebbero essere introdotte con Zend 2.0 (in questo caso, tuttavia, sembra che il team di sviluppo non abbia ancora preso decisioni definitive) sono l'ereditarietà multipla e le variabili private. La prima consiste nella possibilità di creare una classe ereditando funzionalità da più classi; attualmente è supportata solo l'ereditarietà singola (per cui una classe può estendere un'unica classe "madre"). La seconda novità riguarda la possibilità di dichiarare private delle variabili interne ad una classe (variabili membro, nel gergo dell'OOP), rendendole inaccessibili dall'esterno della classe stessa.

Conclusioni
In definitiva le nuove caratteristiche di Zend dovrebbero rendere PHP un linguaggio più credibile per lo sviluppo di applicazioni web, ponendo rimedio (sia pure parzialmente) ad alcune gravi lacune che affliggono la versione attuale. Incrociamo le dita.
TAG: 
26 Commenti alla Notizia Latoserver.it/ PHP: verso Zend 2.0
Ordina
  • Vorrei fare una piccola precisazione, da un punto di vista dewll'ingegneria del software, sull'affermazione:

    "Il nuovo modello ad oggetti renderà possibili istruzioni del tipo $oggetto1->metodo1()->metodo2() dove metodo2() viene invocato rispetto all'oggetto restituito da metodo1(). Questa funzionalità, disponibile in molti linguaggi di programmazione, oltre ad essere di uso molto intuitivo, consente di scrivere codice più sintetico e previene alcuni tipi di errore."

    In realtà un'invocazione di metodi come quella indicata nell'esempio, per quanto possa essere considerata comoda, non previene errori, anzi viola uno dei principi fondamentali dell' Object-oriented Design e cioè la legge di Demeter. Questo può portare a forti limitazioni nella riusabilità e manutenibilità del codice.
    non+autenticato
  • Il linguaggio lo permette ma i buoni programmi li scrivono i buoni programmatori.

    Quello che dici è vero ma stà a chi progetta/sviluppa l'applicazioni applicare il "Don't talk to strangers" Pattern Sorride (altro nome per la Legge di Demeter) come stà a lui il non esagerare (per me è meglio proprio evitare) con la promozione dell'interfaccia per rispettare la legge di Demeter. Molto meglio affidarsi ad un "Expert Pattern"
    non+autenticato
  • tempo fa ebbi uno scambio di mail con l'autore di zend, e rimasi davvero perplesso.

    l'autore aveva pubblicato una pagina web dove sentenziava la maggiore velocità di php rispetto ad asp. a parte l'inutilità della cosa, visto che bisognerebbe ragionare in termini di scalabilità, il ragionamento era del tutto errato: lui metteva a confronto una routine di risoluzione del problema delle torri di hanoi fatta in zend ed una analoga fatta in vbscript.

    scrissi dicendo che in quel modo testava la velocità di zend e di vbscript, non di php e asp, e, volendo, avrei potuto utilizzare un componente scritto in C++ in asp e far "vincere" così asp.

    dopo un po' di email, non c'è stato nulla da fare: php era il più veloce.

    pace all'anima sua...
    non+autenticato
  • > scrissi dicendo che in quel modo testava la
    > velocità di zend e di vbscript, non di php e
    > asp, e, volendo, avrei potuto utilizzare un
    > componente scritto in C++ in asp e far
    > "vincere" così asp.

    Scusami ma non ho capito cosa vorresti confrontare: php usa un solo linguaggio di scripting, mantre asp ne supporta più di uno, anche se il più usato è vbscript.

    Mettiamoci nei panni del programmatore web medio, che non sa usare C++. Ovviamente farà tutto con il linguaggio di script a disposizione, in questo caso php con il suo engine e asp/vbscript con il suo engine. Il confronto mi sembra perfettamente lecito.

    Se poi vuoi confrontare la velocità con il quale passano il controllo ad un'estensione fatta in C++, questo è un altro discorso... ma il punto è proprio questo. Mentre in php di solito fai tutto o quasi in php, con asp ti metti a scrivere moduli COM esterni per mettere una pezza ai limiti di asp.

    Se MS si è affrettata a buttare alle ortiche asp è il suo modello, un motivo ci sarà.

    Ciao.

       Luigi



    non+autenticato
  • Concordo.

    Tra l'altro sotto Win nessuno ti vieta di usare con PHP gli stessi oggetti COM che useresti con ASP.

    Da questo punto di vista la risposta che hai ricevuto è più che corretta.
    non+autenticato
  • > Scusami ma non ho capito cosa vorresti
    > confrontare: php usa un solo linguaggio di
    > scripting, mantre asp ne supporta più di
    > uno, anche se il più usato è vbscript.
    >
    > Mettiamoci nei panni del programmatore web
    > medio, che non sa usare C++. Ovviamente farà
    > tutto con il linguaggio di script a
    > disposizione, in questo caso php con il suo
    > engine e asp/vbscript con il suo engine. Il
    > confronto mi sembra perfettamente lecito.
    >

    e invece no.
    Perche' se tu confronti la velocita' di un loop
    o codice che ci mette 5 minuti ad essere eseguito, non stai facendo un confronto serio per il web.
    S web sono piu' importanti fattori come la scalabilita', la velocita' con cui il sistema risponde (non per forza la velocita' con cui esegue il codice), l'estendibilita' dell'ambiente.
    PHP ha molti moduli, ma devi saper programmare in c per fartene uno.
    In ASP puoi farli anche in vb, che e' molto simile a vbscript e ottieni performance comunque migliori del codice php interpretato.

    > Se poi vuoi confrontare la velocità con il
    > quale passano il controllo ad un'estensione
    > fatta in C++, questo è un altro discorso...
    > ma il punto è proprio questo. Mentre in php
    > di solito fai tutto o quasi in php, con asp
    > ti metti a scrivere moduli COM esterni per
    > mettere una pezza ai limiti di asp.
    >

    non e' mettere una pezza.
    E' ottenere il massimo vantaggio con il minimo sforzo.
    Gl oggetti com in asp, non sono entita' astratte, fini a se stesse, ma girano dentro un apposito middleware (COM+) che ne gestisce il ciclo di vita, le transazioni, la compilazione just in time, il load balancing su piu' macchine etc. etc. tutto questo in maniera trasparente allo sviluppatore.

    > Se MS si è affrettata a buttare alle ortiche
    > asp è il suo modello, un motivo ci sarà.
    >
    > Ciao.
    >
    beh insomma... buttare via non mi pare.
    Asp e' stato per almeno 6 anni uguale a se stesso.
    La cosa in MS che e' cambiata di meno.

    ciao
    non+autenticato
  • PHP presenta caratteristiche che lo rendo inapplicabile per applicazioni Enterprise.
    Ad esempio:
    - non possiede un'unica intercaccia efficiente per l'accesso al DBMS (vedi JDBC o ADO.NET);
    - non gestisce cursori disconnessi;
    - PHP gira in modalita' CGI sui sistemi MS (la modalita' ISAPI e' solo disponibile sulla carta);
    - supporto alla programmazione modesto.

    Oggi se vuoi fare del "transazionale" su WEB la scelta e' tra J2EE e .NET.

    cordialmente
    mn
    non+autenticato
  • mhmm, sono "ignorante" al riguardo, pero' mi interessa l'argomento visto che un po' di PHP lo mastico... rimango perplesso sul fatto che PHP giri solo in modalita' CGI sui sistemi MS. Ammesso che non so cosa sia ISAPI (ignoranza totale) perche' mai uno dovrebbe usare PHP su di un server MS? Io trovo che il fatto che PHP+MySQL giri su win sia piu' che altro comodo per testare in locale i siti... quindi anche se gira solo in modalita' CGI, beh.. amen

    mi potresti fornire qulche link per approfondire l'argomento?
    thanx
    Ale

    - Scritto da: mn
    > PHP presenta caratteristiche che lo rendo
    > inapplicabile per applicazioni Enterprise.
    > Ad esempio:
    > - non possiede un'unica intercaccia
    > efficiente per l'accesso al DBMS (vedi JDBC
    > o ADO.NET);
    > - non gestisce cursori disconnessi;
    > - PHP gira in modalita' CGI sui sistemi MS
    > (la modalita' ISAPI e' solo disponibile
    > sulla carta);
    > - supporto alla programmazione modesto.
    >
    > Oggi se vuoi fare del "transazionale" su WEB
    > la scelta e' tra J2EE e .NET.
    >
    > cordialmente
    > mn
    non+autenticato


  • - Scritto da: mn
    > PHP presenta caratteristiche che lo rendo
    > inapplicabile per applicazioni Enterprise.
    > Ad esempio:
    > - non possiede un'unica intercaccia
    > efficiente per l'accesso al DBMS (vedi JDBC
    > o ADO.NET);

    ADODB (non sono sicurissimo del nome) e MetaBase svolgono in maniera eccellente questo ruolo.

    > - non gestisce cursori disconnessi;

    Cioè?
    Cursori non connessi ad un DB?

    > - PHP gira in modalita' CGI sui sistemi MS
    > (la modalita' ISAPI e' solo disponibile
    > sulla carta);

    La stessa MS è restia ad utilizzare server Windows per i suoi sistemi, quindi anche il problema è solo sulla carta!Occhiolino

    > Oggi se vuoi fare del "transazionale" su WEB
    > la scelta e' tra J2EE e .NET.

    Il problema di .NET è che, al momento, è pienamente operativo solo su piattaforma MS. J2EE è sempre stata una buona tecnologia.

    Ciao!Sorride
    -- Matteo
    non+autenticato
  • > > PHP presenta caratteristiche che lo rendo
    > > inapplicabile per applicazioni Enterprise.
    > > Ad esempio:
    > > - non possiede un'unica intercaccia
    > > efficiente per l'accesso al DBMS (vedi
    > JDBC
    > > o ADO.NET);
    >
    > ADODB (non sono sicurissimo del nome) e
    > MetaBase svolgono in maniera eccellente
    > questo ruolo.
    >

    lo svolgono come script, non come codice compilato..
    e non esiste un modo semplice per scrivere un driver che operi su basi di dati non relazionali per cui non esista gia' il modulo PHP

    es. con ado e ado.net posso scrivere un driver che mi mappa come tabelle e record dei file su disco e delle email.
    E il tutto sara' visibile senza cambiare il codice, ma cambiando solo la stringa di connessione.


    > > - non gestisce cursori disconnessi;
    >
    > Cioè?
    > Cursori non connessi ad un DB?
    >

    esatto
    cursori lato client, eseguo la query, scarico i dati, chiudo la connessione e libero risorse.
    php non li gestisce.

    > > - PHP gira in modalita' CGI sui sistemi MS
    > > (la modalita' ISAPI e' solo disponibile
    > > sulla carta);
    >
    > La stessa MS è restia ad utilizzare server
    > Windows per i suoi sistemi, quindi anche il
    > problema è solo sulla carta!Occhiolino
    >

    ma che dici?
    www.microsoft.com e www.msn.com sono due fra i siti piu' visitati al mondo. ti sei chiesto su cosa girano?

    > > Oggi se vuoi fare del "transazionale" su
    > WEB
    > > la scelta e' tra J2EE e .NET.
    >
    > Il problema di .NET è che, al momento, è
    > pienamente operativo solo su piattaforma MS.
    > J2EE è sempre stata una buona tecnologia.
    >
    > Ciao!Sorride

    resta li fatto che oggi la scelta e' solo fra quei due.

    ciao
    non+autenticato
  • ovviamente su dns bsd
    ecco in che gira
    non+autenticato


  • - Scritto da:   
    > ovviamente su dns bsd
    > ecco in che gira

    ti perdono, perche' non sai cosa dici.
    www.microsoft.com gir su server web microsoft, e su sistemi operativi microsoft.
    Il dns potra' anche girare su bsd, non credo questo infici il fatto che i 20 e piu milioni di pagine serviti al giorno dal sito MS escano da un IIS.

    ciao
    non+autenticato
  • per una volta (!) non posso non darti ragione

    a presto
    godz
    non+autenticato
  • <bastard mode="on" level="9">
    dimenticavo: ci si becca al prossimo exploit di IIS o alla prossima incarnazione di Nimda?
    </bastard>

    ciao
    godz
    non+autenticato
  • - Scritto da: maks
    >
    >
    > - Scritto da:   
    > > ovviamente su dns bsd
    > > ecco in che gira
    >
    > ti perdono, perche' non sai cosa dici.
    > www.microsoft.com gir su server web
    > microsoft, e su sistemi operativi microsoft.
    > Il dns potra' anche girare su bsd, non credo
    > questo infici il fatto che i 20 e piu
    > milioni di pagine serviti al giorno dal sito
    > MS escano da un IIS.

    peccato che ogni dowload venga spostato su macchine *nix. Inoltre Hotmail continua a girare su BSD...
    >
    > ciao
    non+autenticato
  • non sono molto ferrato in php....
    però sul fatto che lavora solo in CGI su sistemi microsoft avrei da ridireA bocca aperta

    puoi spiegarmi bene come fai a capire se ti gira in cgi????
    il php l'ho visto sia su iis (ma avevo qualche prob ) e su apache (andava e va beneA bocca aperta) e in entrambi i casi gira sotto forma di isapi su sistema nt (winzoz 2000)
    non+autenticato
  • > non sono molto ferrato in php....
    > però sul fatto che lavora solo in CGI su
    > sistemi microsoft avrei da ridireA bocca aperta
    >
    > puoi spiegarmi bene come fai a capire se ti
    > gira in cgi????
    > il php l'ho visto sia su iis (ma avevo
    > qualche prob ) e su apache (andava e va bene
    > A bocca aperta) e in entrambi i casi gira sotto forma di
    > isapi su sistema nt (winzoz 2000)

    gira come isapi, ma non e' proponibile come sistema in produzione, perche' e' troppo instabile.

    ciao
    non+autenticato
  • Beh, di questo passo fra qualche anno PHP arriverà ad avere le funzionalità che Python contiene dall'inizio (12 anni fa), mantenendo però una leggibilità nettamente inferiore.

    Perché Python? Eric Raymond su Linux Journal lo spiega molto bene:

    Why Python?
    http://www.linuxjournal.com/article.php?sid=3882

    Per lo sviluppo Web ci sono diversi tool scritti in Python, a partire da Zope, per passare a WebWare, SkunkWeb e Albatross. Il più essenziale e carino, secondo me, è Quixote:

    http://www.mems-exchange.org/software/quixote/

    Provateli, non tornerete indietro. :^)
    non+autenticato
  • - Scritto da: tekNico
    > Beh, di questo passo fra qualche anno PHP
    > arriverà ad avere le funzionalità che Python
    > contiene dall'inizio (12 anni fa),

    commento interessante.
    Conosci per caso qualche buon content management system scritto in python tipo postnuke, per intenderci?
    non+autenticato


  • - Scritto da: ian
    > - Scritto da: tekNico
    > > Beh, di questo passo fra qualche anno PHP
    > > arriverà ad avere le funzionalità che
    > Python
    > > contiene dall'inizio (12 anni fa),
    >
    > commento interessante.
    > Conosci per caso qualche buon content
    > management system scritto in python tipo
    > postnuke, per intenderci?

    zope
    che e' nu serve web totalmente programmabile in pthon

    e' molto di piu' di un CMS

    ciao
    non+autenticato