Linguaggio che abbraccia lo stato mutabile? [chiuso]

Nessuna lingua ha tutte le proprietà che descrivi per ottime ragioni.

Modifica notifiche Il problema principale è il sovraccarico aggiunto al sistema. Alcune versioni di Smalltalk, ad esempio, lo hanno supportato. Altre versioni hanno affermato la mancanza di supporto di questo come una caratteristica significativa delle prestazioni. Come hai detto C # ha INotifyPropertyChange ma deve essere implementato manualmente. Altri sistemi hanno schemi manuali di notifica simili per questo. La specifica Observe di JavaScript ECMA 6 è l'ultimo tentativo di eseguire questa operazione per tutti gli oggetti mutabili in una lingua.

Questo non sarà mainstream fino a quando i problemi di prestazioni sottostanti non potranno essere affrontati in un modo prevedibile e comprensibile.

Tipi di dipendenza L'applicazione di predicati come "car.broken == False" viene generalmente definita come un sistema di tipi di dipendenza; un sistema di tipi che dipende dalle proprietà di runtime degli elementi candidati del tipo. In generale, è stato dimostrato che questa ha una complessità in termini di tempo polinomiale. Ci sono alcuni sottoinsiemi del caso generale che possono essere implementati in tempo lineare, ma nessun linguaggio mainstream ha una cosa del genere. Le annotazioni SAL di Microsoft sono le più vicine che ho visto anche se potrebbero essercene altre che non conosco di.

Questo non sarà mainstream fino a quando i principi e le limitazioni di un sistema di questo tipo non potranno essere compresi senza un dottorato in sistemi di tipi.

Primitive di concorrenza Le primitive di concorrenza di cui atomic è una parte è un argomento molto dibattuto nelle lingue. Ogni lingua è stata adattata, per certi aspetti, per consentire la concorrenza (eccetto JavaScript che è un linguaggio di stato mutevole che ha esplicitamente preso posizione contro la concorrenza della memoria condivisa). Esistono diverse lingue che hanno atomic in una forma o in un'altra, ma si differenziano per la loro implementazione. Sfortunatamente, non esiste un ampio consenso su quale sia la soluzione "giusta" per questo problema. Il pensiero dominante tende a uno stato condiviso non mutabile come l'attuale salvatore, quindi l'ascendenza dei linguaggi funzionali, ma che è al di fuori dello scopo di questa domanda.

Questo non sarà mainstream fino a quando le ramificazioni e le limitazioni dei primitivi non saranno comprese e accettate o dimostrate che possono fare meglio delle scritture atomiche / serrature condivise che predomina oggi modelli di concorrenza di stato condivisi. Questo potrebbe non essere mai mainstream in quanto altri modelli (come quelli funzionali) potrebbero rivelarsi più proficui.

La maggiore difficoltà che vedo con la mutabilità in molti linguaggi di programmazione, e parte della ragione della tendenza verso oggetti immutabili, è che molti linguaggi e framework non fanno distinzione tra valori mutabili, valori immutabilmente incapsulati ed entità. Una variabile di tipo int[] può sempre, se non nulla, contenere un riferimento a un'istanza di oggetto heap di tipo int[] , ma esistono almeno quattro modi diversi in cui tale variabile può incapsulare lo stato:

• Potrebbe identificare un array non condiviso, il cui proprietario è in grado di mutarlo come meglio crede, e servire per incapsulare i contenuti dell'array per conto del proprietario.

• Potrebbe identificare una matrice condivisa con il codice che accetta di non modificarla e serve a incapsulare i contenuti dell'array per conto di chiunque abbia un riferimento.

• Potrebbe identificare un array che è di proprietà di qualche altro oggetto e incapsula una "connessione" con l'oggetto che possiede l'array

• Potrebbe identificare un array che appartiene allo stesso oggetto del riferimento, ma a cui altri riferimenti potrebbero esistere e incapsula sia il contenuto dell'array che una "connessione" con altri oggetti contenenti riferimenti.

Un array che non verrà mai modificato è effettivamente un valore, come lo è un array al quale nessun riferimento esisterà al di fuori del suo proprietario [se un oggetto contiene l'unico riferimento a una raccolta, elementi in quella collezione a cui non è possibile accedere ma attraverso quel riferimento è considerato "dentro" il proprietario del riferimento]. Se esistono più riferimenti indipendenti a un array e il suo valore può essere modificato, allora è un'entità.

Spesso, è opportuno assicurarsi che le cose si comportino come valori; avere valori accidentalmente trasformati in entità è tale da causare bug. Assicurarsi che qualcosa si comporti come un valore richiederà di garantire che non cambi mai, o che tutti i riferimenti ad esso saranno contenuti all'interno di un singolo "proprietario". I valori non condivisi sono spesso tipi molto utili ed efficienti con cui lavorare; sfortunatamente, nessuno dei linguaggi ispirati a Java di cui sono a conoscenza sembrano riconoscerli come un concetto e fornire gli strumenti necessari per lavorare con loro, assicurando che essi non "per sbaglio" accidentalmente e si trasformino in entità.

Quando parli di allegare notifiche di cambiamento alle cose, sembra che tu ti stia inclinando verso una filosofia di "tutto è un'entità". Non raccomanderei davvero una cosa del genere; mentre le notifiche di modifica possono essere buone, avere tutto essere un'entità completamente modificabile può trasformarsi rapidamente in un pasticcio (ad esempio se ObservedObject è di per sé una proprietà mutabile e se un altro oggetto potrebbe voler sapere se la particolare entità identificata da ObservedObject modifiche, che cosa dovrebbe fare se ObservedObject stesso cambia in modo da identificare un'entità diversa?) È molto meglio ridurre al minimo il numero di punti in cui le entità sono collegate l'una all'altra.