Ciao, e benvenuto nella terza puntata della quarantaseiesima stagione. Oggi entriamo in una delle scelte di progetto più profonde e distintive di TypeScript, quella che sorprende chi arriva da altri linguaggi con i tipi. È la risposta a una domanda apparentemente semplice: quando due cose sono dello stesso tipo? TypeScript risponde in un modo particolare, e la sua risposta rivela tutta la sua filosofia. Oggi capiamo: conta la forma, non il nome.
Partiamo dalla domanda, perché è più sottile di quanto sembri. Quando diciamo che due cose sono dello stesso tipo? Prendi due oggetti: come fa il correttore a decidere se uno può stare al posto dell'altro? La maggior parte dei linguaggi con i tipi risponde per nome. Due cose sono dello stesso tipo solo se sono state dichiarate con lo stesso nome, se portano la stessa etichetta ufficiale. Conta il lignaggio, il certificato: se non hai il nome giusto, non passi, anche se sei identico nella sostanza. È una risposta per titolo, per appartenenza dichiarata.
Voglio darti la risposta di TypeScript, perché è diversa e affascinante. TypeScript risponde in tutt'altro modo: due cose sono dello stesso tipo se hanno la stessa forma. Le stesse proprietà, la stessa struttura. Punto. Non importa il nome, non importa se sono state dichiarate separatamente, non importa se non si sono mai sentite nominare l'una con l'altra. Se ha la forma giusta, se ha le parti che servono, allora va bene, combacia. Il nome è irrilevante: conta solo com'è fatto davvero. Questa si chiama tipizzazione strutturale: giudicare dalla struttura, non dall'etichetta.
Voglio spiegarti perché TypeScript abbia scelto questa strada insolita, perché non è un capriccio. Perché? Perché doveva modellare JavaScript con onestà. E in JavaScript, come vedemmo, gli oggetti sono solo sacchetti di proprietà: se una cosa ha un nome e un'età, va bene così, nessuno le chiede il certificato di nascita o da quale stampo è uscita. TypeScript non poteva imporre un mondo di etichette rigide sopra un linguaggio che ha sempre funzionato per forma. Ha dovuto adattarsi alla natura di ciò che stava descrivendo. È la versione controllata, e anticipata, di una vecchia idea: se cammina come un'anatra e starnazza come un'anatra, è un'anatra. TypeScript controlla il camminare e lo starnazzare, ma prima che tu esegua.
Voglio darti i due lati della medaglia, perché ci sono entrambi. Il vantaggio è la flessibilità, e poca cerimonia. Non devi far dichiarare formalmente a ogni cosa a quale contratto ufficiale appartiene: le cose combaciano se combaciano, e basta. Passi qualcosa a una funzione, e se ha la forma richiesta funziona, senza bisogno di parentele dichiarate. È leggero, e molto in linea con lo spirito di JavaScript. Il rovescio, la sfumatura onesta: a volte due cose hanno la stessa forma per puro caso, senza che tu volessi renderle intercambiabili, e TypeScript le considera uguali lo stesso, perché lui guarda solo la forma. La coincidenza di struttura, per lui, è identità.
Voglio darti l'immagine che rende chiara questa idea, perché è vivida. Pensa a un lavoro che assume in base alle capacità dimostrate, non in base a quale scuola ti ha dato il diploma. Fammi vedere che sai fare le cose richieste, dimostrami la forma, e sei dentro, non importa il tuo titolo o da dove vieni. È flessibile, ed è giusto: conta cosa sai fare, non l'etichetta. L'altro approccio, quello per nome, guarderebbe prima il certificato. Ogni tanto, col metodo delle capacità, qualcuno spunta la lista dei requisiti per coincidenza, senza essere davvero la persona giusta: ecco il piccolo prezzo della forma sul nome.
Voglio trarre la lezione generale, perché è più grande di TypeScript. C'è più di un modo di decidere quando due cose sono dello stesso genere: per nome e lignaggio, oppure per come sono fatte davvero. Scegliere la forma invece del nome compra flessibilità, al prezzo di qualche combinazione accidentale. E c'è una lezione più profonda, sotto: la risposta che un sistema dà alla domanda cosa rende due cose uguali rivela la sua intera filosofia. TypeScript, guardando la sostanza e non l'etichetta, ci dice chi è: pragmatico, aderente alla realtà di ciò che descrive, disposto a un po' di imprecisione in cambio di aderenza. Come rispondi a cosa rende due cose la stessa cosa dice tutto di te.
Per oggi ci fermiamo qui. Abbiamo visto una scelta di progetto profonda: come decide TypeScript quando due cose sono dello stesso tipo. La maggior parte dei linguaggi risponde per nome, per etichetta dichiarata. TypeScript risponde per forma: stessa struttura, stesse proprietà, e combaciano, comunque si chiamino. È la tipizzazione strutturale, e l'ha scelta per modellare con onestà JavaScript, dove gli oggetti sono sacchetti di proprietà: la versione controllata del se sembra un'anatra, è un'anatra. Vantaggio, flessibilità; prezzo, qualche combinazione per caso. Come assumere per capacità dimostrate e non per diploma. La lezione: come rispondi a cosa rende due cose uguali rivela tutta la tua filosofia. Nella prossima puntata vediamo i tipi che non scrivi: l'inferenza. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.