PHP8 stabile è stato rilasciato

overclokk

PHP8 stabile è stato rilasciato

PHP 8 stabile è stato rilasciato, qui la notizia https://www.php.net/releases/8.0/en.php

Io devo ancora provarlo ma da quello che ho visto ci sono alcune cose interessanti, ad ogni modo prima di usarlo in produzione meglio verificare se la propria applicazione/sito funziona senza problemi.

juanin

@overclokk si muove verso una tipizzazione un po' più seria diciamo.

overclokk

@juanin Si, e questo è un bene per noi che dobbiamo usarlo.

daniele.diegidio

@overclokk ha detto in PHP8 stabile è stato rilasciato:

verificare

secondo voi è abbastanza retrocompatibile o darà noie di qualche tipo?

overclokk

@daniele-diegidio FInchè non si prova non si può sapere, ad ogni modo non serve passare subito alla versione 8, la 7.4 va ancora bene.

juanin

Il passo grosso è stato 5/7, ma anche la 8 andando su tipizzazione strict qualche fastidio lo darà quindi non vedo particolari cambiamenti enormi, ma va controllato tutto molto bene.

Esempio quegli if che prima ti davano true e ora false potrebbero portarti errori di logica gravi e inattesi pur non dando errori.

giuseppemorelli

Il passaggio da 5 a 7 ha dato il boost performance ma a livello funzioni se non si attiva la modalità strict non è che ci sia questa rivoluzione.

Il passaggio alla versione 8 spero sia la svolta per avere un codice un po' più "pulito" ma se non erro non ha di default la strict type attiva quindi anche qui: boost per via del JIT compiler ma a livello codice ancora non riesce a far chiudere progetti obsoleti tipo Wordpress purtroppo (scherzo @overclokk !)
Dai che forse sta volta almeno lo riscrivono per farlo più moderno sto blog tuttofare

overclokk

@giuseppemorelli Tutta invidia

juanin

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Il passaggio da 5 a 7 ha dato il boost performance ma a livello funzioni se non si attiva la modalità strict non è che ci sia questa rivoluzione.

Rivoluzione no...ma a livello di codice/sintassi le modifiche per il porting sono state sicuramente più impattanti rispetto a quello che vedo tra 7 e 8.

giuseppemorelli

@juanin ha detto in PHP8 stabile è stato rilasciato:

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Il passaggio da 5 a 7 ha dato il boost performance ma a livello funzioni se non si attiva la modalità strict non è che ci sia questa rivoluzione.

Rivoluzione no...ma a livello di codice/sintassi le modifiche per il porting sono state sicuramente più impattanti rispetto a quello che vedo tra 7 e 8.

Probabilmente perchè molto codice su versione 5 era "old-style" e quindi meno ad oggetti/funzionale.

overclokk

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Probabilmente perchè molto codice su versione 5 era "old-style" e quindi meno ad oggetti/funzionale.

E cosa vuol dire per te old-style?

giuseppemorelli

@overclokk ha detto in PHP8 stabile è stato rilasciato:

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Probabilmente perchè molto codice su versione 5 era "old-style" e quindi meno ad oggetti/funzionale.

E cosa vuol dire per te old-style?

Tutto quello che esclude la programmazione ad oggetti: quindi file di sole funzioni
Catene di file con require e include (solitamente c'è solo per il vendor/autoload, il resto è tutto tramite PSR-0 o PSR4 nel composer - il sistema templating rimane escluso da questo discorso)
Nessun pattern di sviluppo
Nessuna programmazione funzionale (array_map esiste da php4 ma solo con php7 l'ho visto usare di più)

overclokk

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Tutto quello che esclude la programmazione ad oggetti

La programmazione ad oggetti è old-style, ha più di 40 anni

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

quindi file di sole funzioni

Avere file con solo funzioni non è un problema di per se.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Catene di file con require e include (solitamente c'è solo per il vendor/autoload, il resto è tutto tramite PSR-0 o PSR4 nel composer - il sistema templating rimane escluso da questo discorso)
Nessun pattern di sviluppo
Nessuna programmazione funzionale (array_map esiste da php4 ma solo con php7 l'ho visto usare di più)

Tutto il resto che hai menzionato sono best practice per avere codice manutenibile e robusto che si dovrebbero sempre applicare qualsiasi sia il paradigma e/o i paradigmi che stai usando.

Più che old-style direi che c'è sempre meno far west perché appunto PHP sta diventando sempre più strict come è giusto che sia.

giuseppemorelli

@overclokk ha detto in PHP8 stabile è stato rilasciato:

Avere file con solo funzioni non è un problema di per se.

Solo se sei in un framework e le funzioni sono di sistema tipo un get_config_path().
Per il resto sviluppare in quel modo per me è la morte: nessun (o non saprei come fare) pattern di sviluppo, testing molto maccheronico.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:
Tutto il resto che hai menzionato sono best practice per avere codice manutenibile e robusto che si dovrebbero sempre applicare qualsiasi sia il paradigma e/o i paradigmi che stai usando.

Direi più uno standard, la best practice è usare una funzione array invece di un foreach.
Usare gli standard PSR dovrebbe essere un obbligo (per lo meno i principali).
Poi è normale che la gente vede PHP come il giochino di tutti se continuamo a fare come 20 anni fa

overclokk

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Per il resto sviluppare in quel modo per me è la morte: nessun (o non saprei come fare) pattern di sviluppo, testing molto maccheronico.

Design pattern esistono per tutti i paradigmi, quelli per OOP sono più conosciuti.

Il testing è maccheronico se il codice è maccheronico e questo può esserlo per qualsiasi paradigma, anche con la OOP.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Direi più uno standard, la best practice è usare una funzione array invece di un foreach

Concordo, anche se foreach è più facile
Ma best practice non vuol dire must practice.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Usare gli standard PSR dovrebbe essere un obbligo (per lo meno i principali).

E qui la penso in modo diverso, conoscere gli standard dovrebbe essere la base ma usarli dovrebbe essere una scelta di design per progetto e non un obbligo, poi dipende anche da quanti dev ci devono lavorare, se sono da solo a sviluppare lo standard me lo creo io (che poi non creo nulla perché sarà comunque un metodo di lavoro che ho acquisito conoscendo gli standard).

Se ho due classi in croce perché dovrei usare la PSR-4?

La PSR-1|2|12 non sono obblighi, come sopra se il progetto è interno il coding style lo si crea internamente.

Se lavoro per un progetto terzo userò il suo standard e non il mio, se devo mandare dei fix al core di WordPress userò i WPCS, se sviluppo un mio plugin scelgo quello che pare a me (che comunque sarà la PSR-2 ma per una mia scelta e abitudine).

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Poi è normale che la gente vede PHP come il giochino di tutti se continuamo a fare come 20 anni fa

Qui la penso come te, il problema principale è proprio per il fatto che PHP è un linguaggio troppo permissivo, è nato così per essere "facile" per i non dev per cominciare ad usarlo rispetto ad altri linguaggi, questa facilità è stata un bene perché ha avvicinato molti alla programmazione ma è stata anche un male perché poi la media è rimasta bassa per molto tempo (e mi ci metto anch'io), quello che oggi vediamo integrato in PHP Java e simili lo avevano anni prima.

giuseppemorelli

@overclokk ha detto in PHP8 stabile è stato rilasciato:

Design pattern esistono per tutti i paradigmi, quelli per OOP sono più conosciuti.

Scusa ma come si fa ad implementare dependency injenction, repository, observer, singleton, interceptor pattern e via dicendo in un file di funzioni? Cavolo se c'è la possibilità sono curioso.

Se ho due classi in croce perché dovrei usare la PSR-4?

Perchè le classi vengono precaricate per namespace nel vendor/autoload.php -> ottimizzazione in velocità
Perchè se da 2 poi diventano 3 non è che devi fare altri include o require, ma basta un composer dump-autoload.

Se iniziamo sempre con il fatto "ah ma è un piccolo progetto, non servono i test non serve un autoload" saranno sempre pezzi di codice buttati là che quando crescono dovranno essere riscritti.
Fare un composer.json per un PSR-4 e 2 classi non è chiedere la luna ma di fatto è una prassi che non fa nessuno a meno che non ci sia di mezzo un framework.

Tanto la prossima versione la saltano e faranno PHP10 come Windows.

"Per un PHP migliore" cit

overclokk

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Scusa ma come si fa ad implementare dependency injenction, repository, observer, singleton, interceptor pattern e via dicendo in un file di funzioni? Cavolo se c'è la possibilità sono curioso.

Se parliamo di programmazione procedurale:
https://stackoverflow.com/questions/10491175/does-procedural-language-have-design-patterns

Volendo si trovano pattern anche per tutti gli altri paradigmi, funzionale, logico ecc.

Aggiungo però una nota: non è che per forza devi implementare quei pattern in tutti i paradigmi per forza, alcuni pattern sono nati per risolvere problemi specifici di un certo paradigma, altri paradigmi non hanno quel problema (che poi iniettare tramite parametro una callback un una funzione è fattibile).

E poi, i pattern vanno imparati e poi dimenticati, quello che importa è l'idea che c'è non l'implementazione che comunque non è scritta nella pietra perché potrebbe cambiare in base alle esigenze del progetto.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

singleton

Il singleton è un anti-pattern e faccio finta di non aver letto

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Perchè le classi vengono precaricate per namespace nel vendor/autoload.php -> ottimizzazione in velocità

Si, che poi comporta problemi di performance se l'applicazione diventa molto grossa ed è per questo che in produzione si lancia un composer dumpautoload -o che non fa altro che creare in modo automatico e non manuale un file con tutte le classi da caricare come faresti senza autoload e usa proprio un include $file.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Perchè le classi vengono precaricate per namespace nel vendor/autoload.php -> ottimizzazione in velocità
Perchè se da 2 poi diventano 3 non è che devi fare altri include o require, ma basta un composer dump-autoload.

Come sempre va valutato in base al progetto, posso averne anche 10 senza autoload e funzionare lo stesso mantenendo sempre una struttura che mi consenta in caso di necessita di poter implementare l'utoload in pochi passaggi.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Se iniziamo sempre con il fatto "ah ma è un piccolo progetto, non servono i test non serve un autoload" saranno sempre pezzi di codice buttati là che quando crescono dovranno essere riscritti.

Non ho mai detto che nei piccoli progetti non si debbano scrivere anche i test
L'autoload come ho scritto sopra puoi sempre implementarlo al bisogno.
I pezzi di codice sono buttati là se li butti là, se parti già ordinato dall'inizio parti avvantaggiato, la OOP non vuol dire ordine.
Tutto prima o poi dovrà essere riscritto, non esiste codice scritto bene la prima volta.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Fare un composer.json per un PSR-4 e 2 classi non è chiedere la luna ma di fatto è una prassi che non fa nessuno a meno che non ci sia di mezzo un framework.

Dipende dal progetto.

Non esiste tutto nero o tutto bianco, in mezzo ci sono tante sfumature di grigio, sono tutte scelte di design che vanno fatte prma e se fatte bene possono essere cambiate durante il processo.

giuseppemorelli

Tanto la questione qua non finirà mai

@overclokk ha detto in PHP8 stabile è stato rilasciato:

E poi, i pattern vanno imparati e poi dimenticati, quello che importa è l'idea che c'è non l'implementazione che comunque non è scritta nella pietra perché potrebbe cambiare in base alle esigenze del progetto.

Questa faccio finta di non averla letta io sta volta. Se ho un progetto ed ho dei dati salvati da qualche parte uso il repository pattern. Sto usando uno standard, non è che ogni volta mi devo reinventare la ruota.
Che poi lo si può implementare in 1000 modi è chiaro, ma la mantenibilità o condivisibilità con altri è molto minore.

Si, che poi comporta problemi di performance se l'applicazione diventa molto grossa ed è per questo che in produzione si lancia un composer dumpautoload -o che non fa altro che creare in modo automatico e non manuale un file con tutte le classi da caricare come faresti senza autoload e usa proprio un include $file.

Se l'applicazione è grande hai problemi anche con gli include, la differenza è sempre l'organizzazione del codice.

Non ho mai detto che nei piccoli progetti non si debbano scrivere anche i test
L'autoload come ho scritto sopra puoi sempre implementarlo al bisogno.
I pezzi di codice sono buttati là se li butti là, se parti già ordinato dall'inizio parti avvantaggiato, la OOP non vuol dire ordine.
Tutto prima o poi dovrà essere riscritto, non esiste codice scritto bene la prima volta.

Questo vuol dire che non usi test statici. In qualsiasi progetto che non sia uno script una tantum andrebbe sempre messo un code sniffer ed ecco che il composer diventa una necessità obbligata.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Fare un composer.json per un PSR-4 e 2 classi non è chiedere la luna ma di fatto è una prassi che non fa nessuno a meno che non ci sia di mezzo un framework.

Dipende dal progetto.

Non esiste tutto nero o tutto bianco, in mezzo ci sono tante sfumature di grigio, sono tutte scelte di design che vanno fatte prma e se fatte bene possono essere cambiate durante il processo.

Rispetto la tua idea ma non sono d'accordo.
Il composer.json non è una scelta di design o di progetto. E' parte fondamentale del PHP al giorno d'oggi e non può mancare.

overclokk

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Tanto la questione qua non finirà mai

È comunque una bella discussione, no? (Che forse dovremmo splittare in un topic a parte)
Il mio intento non è quello di far cambiare idea a te ma è quello di dare al lettore differenti modi per approcciare un problema a cui poi esistono differenti modi per risolverlo, la OOP non è la panacea di tutti i mali.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Questa faccio finta di non averla letta io sta volta. Se ho un progetto ed ho dei dati salvati da qualche parte uso il repository pattern. Sto usando uno standard, non è che ogni volta mi devo reinventare la ruota.

Rispiego meglio quello che volevo dire, non ho detto che i pattern non vanno usati, ho detto che vanno imparati in modo tale che poi il loro utilizzo diventi un processo naturale, non ha senso dire "Qui implementerò questo pattern e qui implementerò l'altro" prima ancora di aver scritto una riga di codice, l'uso dei pattern non deve essere una scelta da fare all'inizio di un progetto e questo non vuol dire reinventare la ruota ogni volta.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Se l'applicazione è grande hai problemi anche con gli include, la differenza è sempre l'organizzazione del codice.

Guarda che è quello che fa composer con il parametro -o crea una classmap e poi usa include dei files nella lista creata.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Questo vuol dire che non usi test statici. In qualsiasi progetto che non sia uno script una tantum andrebbe sempre messo un code sniffer ed ecco che il composer diventa una necessità obbligata.

È obbligatorio se vuoi usare PHPUnit per i test ma non è obbligatorio per far funzionare l'applicazione in produzione.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Il composer.json non è una scelta di design o di progetto. E' parte fondamentale del PHP al giorno d'oggi e non può mancare.

Per progetti che verranno condivisi con altri dev si, per poter gestire le dipendenze si, per altre situazioni dipende.

Se dobbiamo collaborare io e te ad un progetto sicuramente cercheremo di utilizzare un linguaggio comune ad entrambi, in questo caso l'uso degli standard e di strumenti comuni va benissimo perché entrambi li conosciamo e la comunicazione diventa più veloce.

giuseppemorelli

@overclokk ha detto in PHP8 stabile è stato rilasciato:

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Tanto la questione qua non finirà mai

È comunque una bella discussione, no? (Che forse dovremmo splittare in un topic a parte)
Il mio intento non è quello di far cambiare idea a te ma è quello di dare al lettore differenti modi per approcciare un problema a cui poi esistono differenti modi per risolverlo, la OOP non è la panacea di tutti i mali.

Su questo sicuramente un post a parte ci starebbe bene: confrontando però PHP con altri tipo Node.js la differenza sta nel fatto che a mio avviso PHP o lo si gestisce con OOP + composer.json oppure diventa sempre uno spaghetti code.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Questo vuol dire che non usi test statici. In qualsiasi progetto che non sia uno script una tantum andrebbe sempre messo un code sniffer ed ecco che il composer diventa una necessità obbligata.

È obbligatorio se vuoi usare PHPUnit per i test ma non è obbligatorio per far funzionare l'applicazione in produzione.

I test statici con PHP code sniffer, phpstan etc sono questione di sintassi quindi andrebbero utilizzati sempre.
Ti fanno notare se per caso hai una variabile non usata, cicli for annidati etc.
Per carità se non ci sono l'applicazione funziona lo stesso, ma a mio avviso rimane una buona abitudine.

Il paragone è come quando mi dicono: lavoro da solo quindi non ho bisogno del repository git ("ahhh muoio male!").
Certo, puoi farlo ma è a tuo discapito.

@giuseppemorelli ha detto in PHP8 stabile è stato rilasciato:

Il composer.json non è una scelta di design o di progetto. E' parte fondamentale del PHP al giorno d'oggi e non può mancare.

Per progetti che verranno condivisi con altri dev si, per poter gestire le dipendenze si, per altre situazioni dipende.

Rispetto la tua idea ma non la condivido. (Vedi questione repository git)
Metto altre info per portare la scelta del composer:

definisci quale versioni di php supporta il tuo codice
definisci quali librerie php sono necessarie (es. php-json php-xml etc)
definisci la stabilità e versione del codice
definisci licenza, descrizione e nome pacchetto/progetto (non strettamente necessario ma utile)

Inoltre, quale codice ormai non richiede almeno 1 dipendenza? Giusto una coming soon page

Direi di aprire 2 nuove discussioni:

PHP OOP: perchè si e perchè no
PHP + composer.json: perchè si e perchè no

Che ne dici @overclokk ?