Optional è utile in modo ovvio in un linguaggio tipizzato staticamente, ma mi chiedo se sia utile anche in linguaggi dinamici. Di solito non c'è un compilatore che ti dica "hey, hai usato questo Optional<String> come String ", quindi devi ancora scoprire i tuoi errori in fase di esecuzione. Ho uno sfondo di battitura statico e dal mio punto di vista non vedo il vantaggio di un tipo Optional in un linguaggio dinamico.
Questa debolezza non è affatto diversa rispetto ai tipi tutti nelle lingue dinamiche. Devi eseguirlo per scoprire cosa c'è dentro. Le opzioni non sono molto diverse a tale riguardo.
Le opzioni sono più di una semplice annotazione statica che un valore può o non può essere presente. Hanno anche delle operazioni associate a loro. Le catene di operazioni mappate su opzioni sono una funzionalità molto utile, che ti impedisce di dover controllare il fallimento dopo ogni passaggio della catena.
Anche se si recuperava immediatamente il valore, il programmatore avrebbe comunque dovuto controllare la presenza di Nothing la prima volta che è stata eseguita e non è riuscita. Senza un'opzione, la sollecitazione avverrebbe solo se fosse contenuta null la prima volta che l'hai eseguita. Molte denunce di puntatori nulli hanno atteso ostinatamente fino a quando il prodotto non si trovava sul campo.
Posso parlare per Objective-C.
Poiché i linguaggi tipizzati dinamici sono in ritardo, la verifica di un "facoltativo" (un non valore è rappresentato con nil ) è intrinseca: se si verifica il tipo in fase di esecuzione, si verifica per nil implicitamente. Naturalmente questo è concatenabile. Anche questo è fatto in modo intrinseco.
Per i linguaggi tipizzati statici questo concetto in più è un vantaggio, perché devono prendere la decisione del tipo in fase di compilazione - una situazione che le lingue con tipo dinamico non hanno mai.
Leggi altre domande sui tag static-typing dynamic-typing