Novità php 5.3

[Uno]

Ormai è quasi un anno che è stato rilasciato il 5.3 però sinceramente non mi sono mai soffermato a vederne le novità. Di solito è difficile che nelle mie cose mi servano proprio le ultime cose implementate, ho già un mio stile con quello che c'è.
Un post segnalatomi sulla newsletter di Zend A Primer for PHP 5.3's New Language Features - phly, boy, phly mi ha fatto dare un occhio.

Interessante la possibilità di assegnare come nome di una funzione una variabile. Probabilmente non mi servirà mai, inoltre non rischierei di usare novità che magari non si trovano in tutti gli hosting, però potrebbe essere utile in futuro.

[andrea.paiola]

continua a non piacermi questo modo di portare avanti il linguaggio... novità tipo i namespace secondo me dovrebbero stare in una nuova major version, ossia preferirei le mettessero nella 6 e che sviluppassero quella

[Antonio]

continua a non piacermi questo modo di portare avanti il linguaggio... novità tipo i namespace secondo me dovrebbero stare in una nuova major version, ossia preferirei le mettessero nella 6 e che sviluppassero quella

Concordo con quanto dici, anche io mi sto progressivamente disinteressando di PHP a causa della lentezza nello sviluppo di Zend FW e di come gestiscono la roadmap di PHP.

[andrea.paiola]

la lentezza in sè non è un problema grosso per me ( anche se effettivamente PHP ne ha di arretrato da recuperare... ) è che per me le grosse novità vanno inserite solo nelle major version

nuova major version per me vuol dire grosse novità, son sinonimi

all'interno della major version poi continui a sviluppare per risolvere i bug e non per inserire feature!

mi pare che php sia quasi l'unico che si sviluppi in questo modo disordinato

[Antonio]

la lentezza in sè non è un problema grosso per me ( anche se effettivamente PHP ne ha di arretrato da recuperare... ) è che per me le grosse novità vanno inserite solo nelle major version

E non è poco l'arretrato se vuole essere usato in maniera profitevole anche in ambito enterprise (non di alto livello); pare lo abbiano capito che dovevano darsi una mossa facendo nascere lo ZF, il problema è che dovrebbero lavorarci più persone, perché cose basilari come RBAC sono ancora nell'incubator da secoli, senza parlare di xml/rpc o di soap che sono supportati a metà e/o non bene rispetto ad altri linguaggi/fw.

nuova major version per me vuol dire grosse novità, son sinonimi

all'interno della major version poi continui a sviluppare per risolvere i bug e non per inserire feature!

mi pare che php sia quasi l'unico che si sviluppi in questo modo disordinato

E' l'unico progetto di un certo livello in cui le roadmap sembrano scritte dai bambini dell'asilo; aspettavo con ansia PHP6 per avere il supporto unicode nativo, che reputo di gran lunga più importante dei ns; senza contare che andrebbero inclusi anche dei nuovi tipi-oggetto in cui far confluire tutti i relativi metodi (basti pensare agli array ed alle 15000 funzioni, alcune dai nomi assurdi che ci sono).

[andrea.paiola]

ecco concordo perfettamente con Antonio, non avrei potuto scriverlo meglio

fortunatamente mi occupo di altro per lavoro, il lato client

[Valeriano Manassero]

Ho deciso, finalmente, di mettere in "blacklist" ogni tipo di progetto che abbia anche solo una riga di PHP (unica eccezione un portale con vBullettin, ma li ho l'assistenza e se la smazzano loro).

Trovo abbastanza naturale che il percorso di sviluppo di PHP stia facendo sorgere dei dubbi visto che è *sempre* stato gestito in modo pessimo. L'unica fortuna di questo linguaggio di scripting lineare (perchè tale è nonostante il timido tentativo di approcciare l'OOP con risultati davvero risibili), è che anche un ragazzino può scrivere quattro righe di codice con praticamente nessun tool dedicato che ne decreta ancor oggi una grande diffusione. Però, va detto, PHP è anche stato il mezzo con cui più si è prodotto spaghetti code nella storia proprio perchè non ha una "struttura" tale in modo da portarti a lavorare con un analisi approfondita, bensì è un mezzo veloce per tentare un po' di improvvisazione.

Lato sistemistico, poi, è sempre stata una gatta da pelare proprio per un versioning fatto davvero male e che non troppo raramente causava problemi di backward compatibility, per fortuna non ho mai dovuto fare degli shared host perchè, a volte, coi clienti, sono stato costretto a vere e proprie evoluzioni poichè un applicativo voleva quella specifica versione ed il "vicino" voleva la minor successiva (wtf?)

[Antonio]

ecco concordo perfettamente con Antonio, non avrei potuto scriverlo meglio

fortunatamente mi occupo di altro per lavoro, il lato client

Io ogni volta che riprendo in mano PHP mi viene lo sconforto, perché vorrei concludere il cms che ho creato con lo ZF, ma ogni volta che mi servirebbe un componente (RBAC ad es.) vado a controllare e vedo che sì, qualcuno ci ha pensato, ma no, non è peresente ancora nel fw perché finito a metà.

A questo punto qualcuno potrebbe obiettare: perché non ti fai in casa quel componente come più ti piace?

La risposta è che non voglio reinventare la ruota 10^n volte, non voglio certo qualcosa della complessità di drools, ma, cavolo, è da secoli che è presente Zend_Acl, sviluppare anche Zend_Rbac subito dopo, al posto dei moduletti stupidi per interfacciarsi con google api (ad esempio), cosa sarebbe costato?

[Valeriano Manassero]

Io ogni volta che riprendo in mano PHP mi viene lo sconforto, perché vorrei concludere il cms che ho creato con lo ZF, ma ogni volta che mi servirebbe un componente (RBAC ad es.) vado a controllare e vedo che sì, qualcuno ci ha pensato, ma no, non è peresente ancora nel fw perché finito a metà.

A questo punto qualcuno potrebbe obiettare: perché non ti fai in casa quel componente come più ti piace?

La risposta è che non voglio reinventare la ruota 10^n volte, non voglio certo qualcosa della complessità di drools, ma, cavolo, è da secoli che è presente Zend_Acl, sviluppare anche Zend_Rbac subito dopo, al posto dei moduletti stupidi per interfacciarsi con google api (ad esempio), cosa sarebbe costato?

Mi rendo conto che il passo può spaventare, ma hai mai pensato a Rails? (tra l'altro il 3 ha anche Merb integrato)
Ha una struttura MVC invidiabile, scrivi pochissimo codice vista la concisione del linguaggio, fai unit testing con una facilità impressionante ed hai una manutentibilità mostruosamente alta.

[Antonio]

Lato sistemistico, poi, è sempre stata una gatta da pelare proprio per un versioning fatto davvero male e che non troppo raramente causava problemi di backward compatibility, per fortuna non ho mai dovuto fare degli shared host perchè, a volte, coi clienti, sono stato costretto a vere e proprie evoluzioni poichè un applicativo voleva quella specifica versione ed il "vicino" voleva la minor successiva (wtf?)

Io al mio tempo risolsi accontentando gli utenti: niente mod_php e php in fastcgi.
Così puoi avere più versione dell'interprete PHP in esecuzione sullo stesso server (ovvio che devi smazzarti la conf e non è una cosa che i pannelli attuali fanno di default).

Ovviamente i problemi sorgono se un cliente vuole una versione EOL, lì o VPS o dedicato apposito e liberatoria nel caso in cui bucassero qualche applicativo a causa di PHP non aggiornato.

Comunque il problema è proprio PHP ed i suoi sviluppatori; perché le teste di c@zzo che sviluppano in Java o C# et similia ci sono... ma almeno viene data la possibilità anche a chi vuole fare le cose con criterio di farle per bene.

[Valeriano Manassero]

Comunque il problema è proprio PHP ed i suoi sviluppatori; perché le teste di c@zzo che sviluppano in Java o C# et similia ci sono... ma almeno viene data la possibilità anche a chi vuole fare le cose con criterio di farle per bene.

E' chiaro che PHP, come ogni linguaggio, è solo un mezzo. Se vuoi fare spaghetti lo fai anche con qualsiasi altro linguaggio. il problema è che il PHP proprio ti indirizza verso lo spaghetti code, prova ne è il fatto, che ogni sviluppatore che ha a cuore manutentibilità e struttura del codice si basa su un framework aggiuntivo, il che mi pare un po' fuori luogo perchè prova il fatto che il linguaggio da solo mette a disposizione degli strumenti poco riutilizzabili.
Non dico che Rails sia il toccasana di tutti i mali o Java sia sempre adatto a progetti magari piccoli, però proprio siamo su un altro pianeta come struttura applicativa e nel 2010 direi che questo aspetto divide gli applicativi visti come prodotto a quelli visti, in modo più lungimirante, come prodotto su un percorso di miglioramento costante.

[Antonio]

Mi rendo conto che il passo può spaventare, ma hai mai pensato a Rails? (tra l'altro il 3 ha anche Merb integrato)
Ha una struttura MVC invidiabile, scrivi pochissimo codice vista la concisione del linguaggio, fai unit testing con una facilità impressionante ed hai una manutentibilità mostruosamente alta.

Gli ridò una occhiata, comunque PHP lo uso solo in ambito "amatoriale", perché per i progetti di una certa importanza sto usando jboss seam.

Il problema è sempre nel supporto dei suddetti linguaggi sugli shared: non ho problemi a studiarmi un nuovo linguaggio/fw, però vorrei almeno poterlo usare ampiamente senza dovermi fare i problemi relativi al dove piazzare l'applicativo

Per la fase di testing stendiamo un velo pietoso su PHP, ricordo cosa non era il debug anni fa senza xdebug e senza fw per il testing .

[Antonio]

... ogni sviluppatore che ha a cuore manutentibilità e struttura del codice si basa su un framework aggiuntivo, il che mi pare un po' fuori luogo perchè prova il fatto che il linguaggio da solo mette a disposizione degli strumenti poco riutilizzabili.

Infatti, prima di affidarmi allo ZF, usavo librerie fatte in casa; poi ho deciso di passare ad usare lo ZF speranzoso che un giorno PHP si sarebbe avvicinato a Java come modello di sviluppo.

PS: Lo so, ripongo troppe speranze nel prossimo

PS2: mi sai indicare qualche sito/libro dove poter dare una occhiata decente a Merb? Il sito ufficiale non mi sembra abbia poi tutta questa documentazione

[andrea.paiola]

Mi rendo conto che il passo può spaventare, ma hai mai pensato a Rails? (tra l'altro il 3 ha anche Merb integrato)
Ha una struttura MVC invidiabile, scrivi pochissimo codice vista la concisione del linguaggio, fai unit testing con una facilità impressionante ed hai una manutentibilità mostruosamente alta.

anche lì non è molto che c'è il supporto unicode...

Ruby, divertente da usare... sintassi pulitissima e human-oriented, molto object oriented, creato da un giappo pazzo mi pare

Rails, la fortuna di Ruby e dello sviluppo agile... in seguito molti hanno poi copiato ( basta pensare a CakePHP o Symfony )... l'idea di fondo è quella di rilasciare spesso, correggere, testare e rilasciare di nuovo... in continuità quindi si migliora il progetto...

Rails ha un approccio completamente diverso da quello di ZF, ZF permette di essere facilmente integrato con altre soluzioni, caricando ed usando solo una parte dello stesso... Rails ha invece un approccio monolitico e relativamente rigido, ma offre una soluzione alquanto completa includendo ORM, caching, ambienti e test vari...

Ruby e Rails sono ovviamente meno diffusi sui server

un'altra alternativa sarebbe Python e i suoi framework, in particolare Django mi sembra quello più web oriented

Python supporta unicode dalla versione 2.0 ( lasciamo stare la 1.6 )

Python è un linguaggio più serioso ( no, non è vero! ) e prolisso e viene usato per molte altre cose che non sto a citare... ci farei un serio pensierino se si vuole effettivamente abbandonare PHP

poi c'è sempre il mitico gigantesco magnifico Java e i suoi mille progetti

[andrea.paiola]

Il problema è sempre nel supporto dei suddetti linguaggi sugli shared

forse ti conviene mettere più sitini sullo stesso spazio così da ammortizzare i costi anche di soluzioni diverse dal classico LAMP ( guarda per esempio cosa offre Unbit.it )

poi dipende che devi fare, per i sitini veramente ini PHP penso vada benissimo... ma se già vuoi mettere un framework grosso tipo ZF di mezzo non saranno tanto ini...