Primo gennaio 2020 una data veramente particolare per poter iniziare questa nuova avventura insieme io sono BrainRepo e quello che state ascoltando è GitBar il nostro bar per i full stack developer il nostro circolo aperto una volta a settimana dove affronteremo quelli che sono gli argomenti hot più importanti della vita di un full stack dev.L'appuntamento spero di riuscire a renderlo settimanale.Finora Gitbar è un esperimento, un esperimento che nasce appunto da un'esigenza, quella non tanto di insegnare qualcosa a qualcuno anche perché tra di voi ci sono tantissimi full stack dev che sicuramente sono più preparati di me, ma quanto quella di condividere il mio percorso di studio e di apprendimento.Questo perché adesso non ricordo il nome ma un importante fisico sosteneva che il modo migliore per apprendere quello di provare a spiegare perché provando a spiegare si interiorizza di più qualunque cosa appunto si intende apprendere.Quali sono gli argomenti di oggi? Oggi vorrei parlarvi di PHP 7.4.So che non arrivo in tempismo perfetto perché l'uscita è stata il 28 novembre a questo punto dell'anno scorso però quelle che sono le novità introdotte le trovo molto interessanti specialmente tre di queste.La prima di cui voglio parlarvi è lo spread operator non so se vi è mai capitato di vedere in javascript l'assegnazione di un array con tre puntini davanti.Che cos'è lo spread operator? Qual è la sua funzionalità? beh immagina un array merge, l'array merge è quella funzione che unisce un array dentro un altro bene lo spread operator non fa altro che unire due array o due oggetti che implementano l'interfaccia traversable oppure un array è un oggetto che implementa l'interfaccia traversable però lo fa non con una chiamata funzione bensì con un costrutto del linguaggio come funziona? io posso fare "nuovoArray = " e mi definisco un array, quindi array, apertato onda, e al posto di elencare i valori uno per uno, basta che metto tre puntini e il nome di un array contenente questi valori e automaticamente questi valori è come che vengano spacchettati e inseriti uno per uno questo naturalmente può sembrare poco interessante in realtà gli utilizzi sono molteplici per esempio dopo averlo applicato per un po' di tempo mi sono reso conto che in realtà è molto più snello da scrivere e tiene il codice decisamente più snello ci sono anche degli altri altri vantaggi rispetto alla re-emerge, beh senza dubbio uno dei vantaggi è la performance.Infatti lo Spread Operator essendo un costrutto del linguaggio è decisamente più performante rispetto all'ArrayMerge che invece è una chiamata a funzione e questa performance emerge quando si prende in considerazione un array di costanti, proprio possiamo vederla in modo evidente.Tra l'altro un'altra cosa molto interessante rispetto allo spread operator rispetto alle re-emerge e che supporta anche gli oggetti traversable cosa che invece la re-emerge non supporta.Tra l'altro lo spread operator possiamo utilizzarlo in diversi contesti per esempio si possono decomprimere array a più livelli ovvero io posso decomprimere un array in un array che però poi verrà decompresso su un altro array oppure possono essere decompressi anche i risultati di una chiamata funzione se questi sono array o oggetti che implementano l'interfaccia traversable tra l'altro si può utilizzare anche sulla generator syntax non so se vi è mai capitato di usare la parola chiave HILD bene in questo caso appunto si può usare lo spread operator ci sono però delle indicazioni delle chiamiamola dei limiti di questo costrutto intanto non supporta gli array passati per riferimento e poi invece la cosa che trovo più limitante è il fatto che per mantenere il supporto con lo spacchetto degli argomenti introdotto con php 5.6 che non è altro che lo spread operator però applicato agli argomenti di funzione non sono consentiti array con chiavi non numeriche e questo per me è la limitazione più importante perché perché in realtà io già lo spread operator lo uso costantemente in javascript l'esempio più semplice è quando voglio clonare un oggetto e magari cambiare una una sola proprietà.Cosa farò? Semplicemente creerò un nuovo oggetto, farò lo spread dell'oggetto che voglio clonare all'interno del nuovo oggetto e poi tra le proprietà ci metterò la proprietà che mi interessa modificare.A questo punto avrò un nuovo oggetto con un nuovo riferimento e con i valori uguali all'oggetto che intendevo clonare, a differenza del valore che vado a sovrascrivere.Questo è molto utile per esempio quando noi lavoriamo su stati, io per esempio lo utilizzo tantissimo quando vado a lavorare su stati nelle mie applicazioni, nel frontend delle mie applicazioni con Vue.js questo perché aggiornando completamente l'oggetto di tipo data io ho semplicemente la rigenerazione dell'albero di visualizzazione e il refresh automatico di tutti i componenti visivi dalla pagina.Quindi questa cosa non può ancora essere fatta e secondo me è una delle implementazioni necessarie per rendere davvero lo Spread Operator uno strumento ancora più potente e ancora più utile.Un'altra funzionalità che è secondo me importantissima è la Raw Function.Tantissimi di voi hanno sentito parlare delle closure, immagino tutti.Le closure non sono altro che delle funzioni anonime alle quali si può passare attraverso la parola chiave "use" il contesto.cosa vuol dire? Intanto sono delle funzioni senza nome che possono essere create, generate all'interno del nostro codice e queste sono caratterizzate da solitamente possono avere delle variabili, dei parametri e possono restituire dei risultati in più all'interno di queste funzioni possono essere iniettati, chiamiamola così, delle variabili attraverso la parola chiave "use".Bene, la stesura di queste closure function era comunque abbastanza prolissa, era veramente verbosa, aveva bisogno di tantissime parole chiavi, per esempio dovevi scrivere "function" aperta tonda, passare i parametri, chiusa tonda, "use" aperta tonda, passare il contesto, lo scope quindi, chiusa tonda, aperta graffa, chiusa graffa e dentro il codice naturalmente diventava esageratamente prolisso e il nostro codice risultava poi alla fine abbastanza disordinato bene questo è stato superato con l'introduzione delle short arrow function short arrow function che non sono altro che diciamo una versione in php delle famose arrow function che troviamo in tanti linguaggi come per esempio che ne so javascript piuttosto che scala e sono diciamo abbastanza sintetiche abbastanza concise da scrivere infatti la sintassi è fn per dichiare la funzione aperto apprendisi tonda i parametri passati all'arrow function, chiusa l'apprendisi tonda, un uguale e un apprendisi angolare chiusa per andare a formare appunto la freccetta, la famosa arrow function e poi un'istruzione che deve avere un valore di return.Bene, infatti una cosa importante da notare sulle arrow function è che una sola istruzione con valore di return è concessa.Su questo in realtà la comunità si è diciamo confrontata parecchio.In realtà ci sono state diverse proposte di implementazione di Arrow Function.Quella che è emersa è quella di cui vi sto parlando e tra le varie implementazioni c'è stata anche qualcuna che prevedeva la possibilità di creare delle arrow function multilinea.Naturalmente questa funzionalità non è passata alle votazioni e Nikita Popov uno dei membri della comunità PHP uno tra l'altro dei più attivi nonché ingegnere a JetBrains la società che produce il famoso editor PHPStorm riassume in poche parole questa scelta di non implementare la arrow function multiline dicendo che sarebbe praticamente un'implementazione che andrebbe contro il principio della stessa arrow function il principio dell'arrow function è la sinteticità bene la reintroduzione delle parentesi graffe della parola chiave return eliminerebbe quindi quel vantaggio necessario tra l'altro parola chiave return e parentesi grafe necessarie nel caso si trattasse di una funzione multilinea dicevo si perderebbe il vantaggio appunto che le arrow function introducono per cui la comunità ha scelto appunto di non permettere la creazione di arrow function multilinea in realtà quali possono essere gli sviluppi futuri di questa funzionalità? beh se io dovesse immaginare dove vorrei trovarle anche se probabilmente mi metterei parte della community php contro per ovvi motivi che poi magari vi spiego ehm sono nelle getter e nei setter perchè? perchè solitamente la stesura di getter e setter è veramente impegnativa.Bene, con le Arrow Functions sarebbe veramente comodo poter generare dei Getter e dei Setter così on-fly semplicemente utilizzando quella Synthasys.Perché dico, ho detto prima, mi metterei la community contro? Perché in realtà sono ben consapevole che ad oggi l'utilizzo dei Getter e dei Setter, specialmente in quelle che sono le classi del model è abusato è un approccio alla programmazione domain driven ci stimola a non utilizzare in modo esagerato getter e setter ecco quello che è il motivo semplificando la creazione appunto di questi metodi probabilmente stimoleremo anche l'abuso naturalmente può essere usati con parsimonia può essere senza dubbio un modo per rendere più rapida la nostra stesura del codice quando noi usiamo le closure solitamente abbiamo necessità di passare attraverso la parola chiave use un contesto, delle variabili di contesto bene nella raw function questa non è necessario questo perché in realtà in modo completamente automatico viene iniettato il contesto nella quale l'arrow function si trova per cui tutte le variabili accessibili nello scope dove si trova l'arrow function sono di conseguenza accessibili all'interno dell'arrow function stessa c'è però da fare un un piccolo appunto che secondo me è uno degli elementi da tenere a mente per evitare di perdere ore in fase di debugging tutti i le variabili di contesto che automaticamente vengono iniettate all'interno della row function sono passate per valore questo vuol dire che se noi modifichiamo in qualche modo una di queste variabili all'interno della nostra row function questa modifica sarà disponibile solo all'interno della nostra row function e non verrà proiettata nel contesto superiore per cui attenzione l'ultima cosa da dire riguardante l'error function è che in realtà è disponibile in accesso anche la variabile "dis" il puntatore appunto all'oggetto corrente per cui non dobbiamo in nessun modo passarlo esattamente come non dovevamo passarlo nell'utilizzo delle closure chiudiamo poi la puntata di oggi parlando delle "Typed Properties" come tutti sappiamo PHP è un linguaggio con un sistema di tipi dinamico questo vuol dire che durante l'esecuzione, quindi in fase di run time il valore di una variabile può essere modificato e insieme al valore di una variabile che può essere modificato ne può essere modificato anche il tipo per esempio io inizializzo una variabile con una stringa durante l'esecuzione questa variabile può accettare e può salvare al suo interno un intero.Questo non è possibile invece su linguaggi strettamente fortemente tipizzati come per esempio il linguaggio Scala, Java e via dicendo.Questi linguaggi invece nel momento in cui io dichiaro una variabile e dico che quella variabile conterrà o dovrà contenere un intero, quella vadiabile non potrà in nessun modo contenere una stringa piuttosto che un array.Naturalmente la dinamicità dei tipi è stata una dei punti di forza di PHP.Con la sua evoluzione però e con l'adozione in ambienti di tipo enterprise è nata l'esigenza di utilizzare dei sistemi di tipi un pochino più evoluti ed ecco che qualche tempo fa è stata inserita la possibilità di dichiarare i tipi nel linguaggio PHP questo vuol dire che da qualche tempo possiamo dichiarare il tipo della variabile passata tra i parametri di una funzione possiamo dichiarare il tipo del valore di ritorno di una funzione e da oggi con PHP 7.4 possiamo dichiarare il tipo di una proprietà della classe.Questo però ha in qualche modo diviso la comunità di PHP che si interroga su quello che può essere il futuro di questo linguaggio.Naturalmente c'è da fare un appunto, il sistema di tipi di PHP è abbastanza basico rispetto a sistemi di tipi più evoluti come quelli per esempio che possiamo trovare nei linguaggi funzionali tipo Scala.Però in qualche modo abbastanza efficace, efficace nel verificare, nel prevenire alcuni errori ancora prima della fase di runtime.Questa è una cosa molto interessante specialmente in ambienti enterprise perché prima si prevengono gli errori e meno errori in produzione ci si trovano la comunità, vi dicevo, si è spaccata in realtà una parte della comunità sostiene che questa direzione questo andare verso un sistema di tipi sempre più evoluto potrebbe in qualche modo portare a un problema in php il problema sta nel fatto che esistono dei programmatori che adorano la possibilità di una gestione dinamica dei tipi perché permette maggior dinamicità nella stesura del codice, di utilizzo delle variabili e via dicendo.Naturalmente cosa dice questa parte della comunità? Se questo utilizzo dei tipi verrà applicato da librerie condivise e di ampio uso come PHP unit o che ne so le librerie prodotte da symphony in qualche modo costringerà anche gli amanti appunto di questo tipo di libertà nel non utilizzo di un sistema della dichiarazione del tipo costringerà a convergere verso appunto un approccio alla programmazione più type oriented e questo in qualche modo potrebbe secondo appunto questa branca di programmatori questo gruppo di programmatori danneggiare il linguaggio php dal mio punto di vista i tipi sono stati assolutamente una rivoluzione benvenuta per questo linguaggio questo linguaggio ampiamente adottato probabilmente anche per la sua semplicità però vi posso dire che sviluppando in ambito enterprise i tipi spesso mi hanno salvato da problemi abbastanza importanti che non riuscivo a vedere.C'è però da fare un piccolo appunto.Ad oggi il PHP ha a disposizione strumenti molto performanti per l'analisi statica del codice.Magari una di queste puntate ci fermeremo un attimo proveremo a capire che cos'è l'analisi statica del codice uno di questi è appunto php-stan talmente performante che si dice che il sistema dei tipi potrebbe non essere necessario quindi comunque ritornando a me io li uso abbondantemente e vi posso dire che per esperienza personale mi han cambiato completamente il modo di programmare detto questo penso di essermi dilungato un po' troppo rispetto a quelli che erano i miei piani probabilmente avrete notato che all'interno di questa puntata ho ferocemente violentato l'italiano beh, sono uno sviluppatore non un poeta quindi abbiate pazienza e se vi fa piacere potete contattarmi su twitter @brainrepo oppure venire a visitare il nostro sito web www.gitbar.it per qualunque comunicazione info@gitbar.it ci sentiremo la prossima settimana con la speranza che questo podcast vi sia interessato in qualche modo un saluto da Brain Repo e buon anno a tutti
