Perché il compilatore Scala non può dare un avviso di corrispondenza dei modelli per classi / tratti non sigillati?

Se uso un un seal traito abstract classin Scala e poi uso pattern matching, mi chiedo, il compilatore non sa al momento della compilazione per questo particolare patternmatch quali possibili implementazioni di questo tratto / classe sono disponibili? Quindi, in caso affermativo, non potrebbe dare avvisi di corrispondenza del modello anche se il trait/ abstract classnon è sigillato perché sa quali tipi potrebbero essere usati, controllando tutte le possibili dipendenze / importazioni?

Ad esempio se ho un Option[A]e faccio pattern matching solo per Some[A]ma non per None, il compilatore si lamenterà, perché Optionè sigillato.

Se il compilatore non può saperlo / risolverlo, perché non può? E se il compilatore (teoricamente) può farlo, quali sono i motivi per cui non viene utilizzato in Scala? Ci sono altre lingue che supportano quel tipo di comportamento?

Capire tutte le sottoclassi di una classe si chiama Class Hierarchy Analysis e fare CHA statico in un linguaggio con caricamento di codice dinamico equivale a risolvere il problema di Halting.

Inoltre, uno degli obiettivi di Scala è la compilazione e la distribuzione separate di moduli indipendenti, quindi il compilatore semplicemente non può sapere se una classe è sottoclassata in un altro modulo, perché non guarda mai più di un modulo. (Dopotutto, potresti compilare un modulo sull'interfaccia di qualche altro modulo senza che quel modulo esista sul tuo sistema!) Ecco perché sealedrichiede che tutte le sottoclassi siano definite nella stessa unità di compilazione.

Questo è anche uno dei motivi per cui le JVM possono competere in modo così favorevole con i compilatori C ++: i compilatori C ++ sono in genere compilatori statici, quindi non possono in generale capire se un metodo viene sovrascritto o meno e quindi non possono incorporarlo. Le JVM OTOH, in genere sono compilatori dinamici, non hanno bisogno di eseguire CHA per capire se un metodo viene ignorato o meno, possono solo guardare la Gerarchia di Classe in fase di esecuzione. E anche se in un secondo momento nell'esecuzione del programma arriva una nuova sottoclasse che non c'era prima, niente di grave, ricompilare quel pezzo di codice senza incorporare.

Nota: tutto ciò si applica solo all'interno di Scala. JVM non ne ha idea sealed, quindi è perfettamente possibile sottoclassare le sealedclassi da un'altra lingua JVM, poiché non c'è modo di comunicarlo in un'altra lingua. La sealedproprietà è registrata nell'annotazione ScalaSig, ma i compilatori di altre lingue non tengono conto di tali annotazioni, ovviamente.

Esso può essere fatto (almeno per tutte le classi noti al momento della compilazione), è solo costoso. Distruggeresti completamente la compilazione incrementale, perché tutto ciò che contiene una corrispondenza di pattern dovrebbe effettivamente essere ricompilato ogni volta che qualsiasi altro file viene modificato.

E cosa stai comprando? È un odore di codice scrivere combinazioni di pattern che devono cambiare frequentemente quando viene aggiunta una nuova classe derivata. È una violazione del principio aperto / chiuso . Usa l'ereditarietà correttamente e non avrai bisogno di scrivere quel tipo di corrispondenze di modelli. E sì, il principio di apertura / chiusura si applica anche ai linguaggi funzionali senza eredità basata sulla classe. Infatti tra funzionalità come classi di tipi, multimetodi e semplici funzioni di ordine superiore, i linguaggi funzionali rendono l'estensione senza modifiche molto più semplice.