Newsgroup: it.comp.www.php
Titolo: PHP 7

Qualcuno ha voglia di parlarne? :)
 
bye!

 
 
Io ne avrei, ma ne so meno di nulla :)
M'hai dato un motivo in più per andare a vedere le ultime news: o già c'è
qualcosa di sicuro?
 
Ciao!

 c'è qualcosa di sicuro?
 
Di sicuro ci sono lo spaceship operator, che non ho ancora ben capito cosa 
fa, e il typehinting coi tipi base (opzionale per file).
 
Oltre alle prestazioni quasi raddoppiate rispetto alla 5.6. :)
 
Bye.

 
 
Questo m'incuriosisce molto: ma è doppia rispetto alla 5.6 perché in quella
versione hanno fatto un gran casino o è doppia rispetto alle precedenti, e
in quel caso che è successo? :O
 
Ciao!

 precedenti, e in quel caso che è successo? :O
 
È doppia rispetto alle precedenti. Anche l'occupazione di RAM è calata 
molto, soprattutto per gli array.
 
Parte dell'aumento penso sia anche dovuto proprio alla diminuzione di 
roba da spostare in RAM, ma il grosso è nella modifica dell'algoritmo di 
garbage collection, che ha portato anche a una semplificazione del 
reference counting, quindi il motore fa meno cose quando accedi a una 
varibile o a una funzione.
 
Inoltre diverse funzioni sono state ottimizzate, il JIT è stato cambiato, 
ecc. ecc.
 
La concorrenza di HHVM ha portato qualche frutto.
 
Bye.
 

 
 
Azz - mi sa che allora sono rimasto incredibilmente indietro sugli sviluppi
del motore.. Devo assolutamente cercare di ritagliarmi un po' di tempo per
leggermi un po' di dettagli.
Grazie della dritta!
 
Ciao!

 Perfetto, strict-on toda la vida! :D
 
Ma infatti! D'altronde se hanno lavorato su questa strada un motivo
ci sarà! *Devono* offrire questa possibilità per rendere il linguaggio
ancora più competitivo verso la concorrenza.
 
Per una veloce disanima ecco un link interessante:
 
"Il PHP 7 diventa severo"
 
http://www.innoteam.it/blog/il-php-7-diventa-severo/
 
 
 
 


 
Poi ci daranno la possibilità di compilarlo, tanto già compiliamo il JS (con
i compressor) e il CSS (da LESS o SASS) e, grazie a $,& e[], insieme a tante
nuove sintassi sbiruline, potremo tra qualche anno tornare a scrivere
applicazioni web come si faceva in perl vent'anni fa.
 
Non sono sarcastico, io ci spero proprio! :)
 
Ciao!

 ancora più competitivo verso la concorrenza.
 
Sono in parziale disaccordo.
 
Sono contento che l'abbiano aggiunto, ma sono ancora più contento che sia 
opzionale.
 
Se PHP diventasse un linguaggio strict, cosa lo renderebbe migliore di, 
per esempio, Scala, Java, Go, ecc.?
 
Dal lato dinamico è già pressato da Node.js e Ruby.
 
È un tentativo (ben riuscito) di tenere il piede in due scarpe, ma è solo 
l'inizio, se vuole combatterli tutti insieme. Per esempio non si possono 
sovraccaricare gli operatori standard; i tipi base non sono oggetti; non 
si possono estendere classi al di fuori della classe stessa; non si 
possono definire conversioni implicite.
 
Ecc. ecc.
 
Una volta che inizi a muoverti verso i tipi strict ci sono parecchie cose 
che la gente si aspetta, e da quando uscirà PHP7 (se non prima) 
inizieranno i lamenti di quelli che non le trovano, e che diranno "eh, ma 
allora passo a..."
 
Bye.

 
 
E' un buon punto di vista.
 
Secondo me bisogna cercare di ricordare perché il PHP è diventato famoso
in primo luogo: risparmio storia e voli pindarici che tanto ci siamo passati
in prima persona tutti, ma tanto per riassumere..
1- le alternative erano pessime. Prima le JSP, che erano nate non per
soppiantare il CGI, ma per forzare il Java in gola agli sviluppatori web, poi
l'ASP, che era nato solo per fare una misera concorrenza alle JSP.
2- mod_php di apache - che è rimasto per anni uno dei motivi principi per
scegliere PHP rispetto a qualsiasi altro linguaggio/ambiente.
 
Il PHP è stato un linguaggio di m**da per tutti da sempre. Nessuno con un 
briciolo di buon senso ha mai detto il contrario. Non sono nemmeno mai riusciti
a mettere in ordine i parametri delle funzioni standard, figuriamoci il
linguaggio stesso. Comunque...
Dalla 3.x in poi, visto che la cosa diventava seria, hanno cominciato a
provare a renderlo più "enterprise", in un modo o nell'altro. Prima le classi
-e ok- poi le traits -e tutti:"che?"- poi odori di funzionale ma tanto ormai
già gli sviluppatori web erano così avvezzi al JS che l'innovazione suonava di
vecchio prima dell'uscita.
 
Nel frattempo veniva su Python, Ruby, e poi NodeJs - che per quanto come
idea faccia ancora ridere ha avuto i suoi seguaci. Contemporaneamente c'è
stato il periodo d'oro degli application-framework/web-framework/servlet-
container (o come li volete chiamare, un web-server integrato) e in seguito
FCGI, che rendevano sempre più dubbioso il vantaggio di apache+mod_php.
 
Ad oggi, il PHP tiene testa per l'immensa quantità di codice già presente
e di sviluppatori professionisti (e non) che danno a privati ed aziende più
fiducia verso il linguaggio stesso.
 
IMHO, PHP è (e se non lo è già, lo diventerà) il FORTRAN del 2K.
 
M2C,
Ciao!

 M2C,
 
Io spero tu ti sbagli perché a me il php sta molto simpatico ma io non
sono un programmatore. In effetti PHP vuol dire personal home page e
quindi è un linguaggio che ai principianti non può che stare simpatico.
 
Comunque la tipizzazione è una caratteristiche che anche a me mancava in
alcune situazioni, a volte la conversione tra tipi non mi è chiara e
quindi con la tipizzazione strict sarebbe stato più semplice non avere
bachi e fare quello che volevo senza dovere conoscere tutte le regole
della conversione tra tipi fatta automaticamente dal linguaggio.
 
M2C :)
 
-- 
Sandro kensan 
www.kensan.it
 & 
www.qiqi.it
 geek site
Saluto gli agenti della NSA - Hello NSA - 
www.nsa.gov
 

 sempre più dubbioso il vantaggio di apache+mod_php.
 
Python, Ruby e Node che, messi tutti assieme, non sono mai arrivati oltre 
il 15% del mercato, mentre gli application framework ormai sono relegati 
sotto la soglia del 5% e scendono.
 
Il motivo? Secondo me perché sono troppo pesanti e complessi.
 
Molti preferiscono partire a prototipizzare un'applicazione e vogliono 
avere qualcosa funzionante in giornata, per vedere come procedere dopo. E 
si sa che non c'è niente di più definitivo di un prototipo tirato su in 
poche ore.
 
Con un application framework, in un giorno non hai ancora finito di 
configurare il server che dovrà ospitarlo, figurarsi scrivere codice.
 
La forza di PHP è sempre stata quella di opporre la minima frizione per 
lo sviluppo di un progetto. Dovuto a mod_php, alla possibilità di 
mischiare HTML e PHP nello stesso file, alla possibilità di programmare 
procedurale e non solo a oggetti, a una libreria standard estesissima e 
che include tutto quello che serve per partire, ecc. ecc.
 
Se/quando questa frizione aumenterà e ci saranno linguaggi che ne hanno 
una più bassa, allora PHP inizierà a perdere quote.
 
Python è sempre stato troppo complesso e mal documentato per riuscirci. 
Ruby quasi uguale. Node.js ci sta riuscendo, ma la necessità di installare 
quasi tutto via npm e la miriade di conflitti che genera non aiutano. 
 
E il fatto che siano praticamente tutti in forma di "application server" 
costringe a stare attenti ai memory leak, a chiudere le risorse, e a un 
sacco di particolari a cui, con PHP, non badi nemmeno, perché dopo 
qualche centesimo di secondo il processo PHP finisce e viene ucciso, e 
tutte le risorse liberate dal SO.
 
E mi stupisce come tutti continuino su questa strada (Scala, Go, Rust) 
invece di fare come PHP e fornire, per esempio, un "microkernel" come 
application framework che lancia e uccide sottoprocessi indipendenti.
 
</rant>
 
Bye.

 ha scritto:

No ferma ferma! Un file .js compresso NON è un file compilato!
E' semplicemente un file sorgente "compattato" e ripulito da
caratteri non necessari all'interprete di turno. Ovvio che
può intervenire anche l'offuscamento degli identificatori
e/o dei nomi di funzione, ma il succo rimane uguale.
Stessa cosa per un file .css, il processamento tramite LESS o SASS
è una "traduzione" da una metodologia di scrittura abbreviata (con
opportune commodities) verso un file in puro CSS.
 
Le "nuove sintassi sbiruline" come le chiami tu :-D non sono
altro che miglioramenti tecnologici alle volte un po' astrusi
ma anche necessari per evolvere la capacità sintattica e di
sintesi di un particolare linguaggio. Tieni anche conto che
l'intento è da anni quello di cercare di far evolvere i linguaggi
applicando sintassi simili (o cmq che prendono spunto) a quelle dei
linguaggi 4GL.
 
E onore al Perl che ai tempi d'oro del web facevo bene il suo
sporco lavoro :-D
 
 

 
 
Era per dire che comunque abbiamo già re-infilato uno step aggiuntivo (che
tradizionalmente era quello di compilazione) nel processo.
E comunque il "traduttore" (come lo chiami te) LESS a CSS è a tutti gli
effetti un compilatore ;)
 
Ciao!

 
 
Il fatto è che a livello d'architettura quella di PHP è una scelta infelice,
ma effettivamente in pratica offre più vantaggi di quanti nessuno credo si
sarebbe potuto aspettare.
 
Chissà, staremo a vedere :)
 
Ciao!

per la questione performances posso dirvi che i miglioramenti sono veramente tangibili e mirabolanti: ho provato una applicazione symfony su php 5.6 e poi in una macchina vagrant con php7, i tempi di risposta sono dimezzati e l'ingombro in memoria è pari a 1/4 !!!

a proposito, voi avete notizie di sistemi di cache disponibili per php7? apcu al momento non funziona...

a proposito, voi avete notizie di sistemi di cache disponibili per php7? apcu al momento non funziona...
 
apcu non funziona, IIRC, da mo'. E' sostituito da "opcache". Ma dipende cosa
ci devi fare. Cioe' se il loading e la compilazione sono piu' del 10-20% del
tuo costo macchina, allora ha senso. Se no e' piu' conveniente vedere dov'e'
che perdi piu' tempo, e cercare di ottimizzare quello.
 
Leonardo
 
-- 
A stultis ex omnibus gentium varie pictis
A sanctae fidei adeptis, ab eorum odore;
AB insanis Iacobinis, ab eorum ardore
AB idolatris et martyribus odii et terroris;
A paradisi fautoribus dicentibus "est pro amore",
A manichaeis ululantibus "Nisi nobiscum prodes";
LIBERA, libera, libera, libera nos, Domine.

 apcu al momento non funziona...
 
Ammetto di non averlo mai provato, ma dovrebbe essere già incluso nel 
core di PHP dalla 5.6 (o 5.5, non ricordo), quindi anche nella 7.
 
Bye.

Ciao,
ok per opcache, so che è stato introdotto già nel php 5.5, ma opcache non svolge tutti i compiti di apc
 
"The only important thing to remember when migrating from APC to OpCache is the fact that the latter doesn't work as a data caching engine. If you have already implemented APC, you may be using its apc_add() and apc_fetch() functions which serve as an interface to a data caching service. OpCache is only a bytecode caching engine so it won't offer a similar functionality. If you're planning to switch from APC to OpCache, remember to consider this limitation. Keep in mind that if you want to keep APC userland functionality, there's the APCu project"
 
Per questo motivo ho bisogno di un 'data caching service', e purtroppo ad oggi APCu (che è il successore di APC, di cui mantiene il data caching e delega ad opcache l'opcode caching) non funziona con php 7

 non svolge tutti i compiti di apc
 
Ah, ora ho capito. Ti serve un in-memory cache. Hai dato un occhio a 
memcache? Hai lo svantaggio di dover installare un server (ma comunque 
devi installare anche apcd, quindi non credo per te sia un problema), ma 
di contro puoi condividere la cache anche con software scritti in altri 
linguaggi (node, python, ruby, ecc.) che girano sul server.
 
Bye.

memcache?
 
Gia' che c'e' potrebbe dare un occhio a Redis.


ottime idee, grazie mille per i suggerimenti!
 
spero comunque che presto arrivi APCu, in questo modo potrò sperimentare il suo funzionamento ed eventuali guadagni in performance usando memcache o redis.