C# ha un modo per simulare la memoria transazionale del software, su piccola scala?

Question

C# ha un modo per modificare temporaneamente il valore di una variabile in un ambito specifico e ripristinarlo automaticamente alla fine dell'ambito/blocco?

Per esempio (non reale il codice):

bool UpdateOnInput = true; 

using (UpdateOnInput = false) 
{ 
    //Doing my changes without notifying anyone 
    Console.WriteLine (UpdateOnInput) // prints false 
} 
//UpdateOnInput is true again. 

EDIT:

Il motivo che voglio quanto sopra è perché io non voglio fare questo:

UpdateOnInput = false 

//Doing my changes without notifying anyone 
Console.WriteLine (UpdateOnInput) // prints false 

UpdateOnInput = true 

Answer 1

No, non c'è modo di farlo direttamente. Ci sono alcune diverse scuole di pensiero su come fare questo genere di cose. Confrontare e contrapporre questi due:

originalState = GetState(); 
SetState(newState); 
DoSomething(); 
SetState(originalState); 

vs

originalState = GetState(); 
SetState(newState); 
try 
{ 
    DoSomething(); 
} 
finally 
{ 
    SetState(originalState); 
} 

Molte persone vi diranno che il secondo è "più sicuro".

Non è necessariamente così.

La differenza tra i due è ovviamente il secondo ripristina lo stato anche se DoSomething() genera un'eccezione. È meglio rispetto a mantenere lo stato mutato in uno scenario di eccezione? Cosa lo rende migliore? Si è verificata un'eccezione imprevista e non gestita che segnala che qualcosa di orribile e è inatteso.Il tuo stato interno potrebbe essere completamente incoerente e arbitrariamente incasinato; nessuno sa cosa potrebbe essere accaduto al punto dell'eccezione. Tutto quello che sappiamo è che DoSomething stava probabilmente cercando di fare qualcosa allo stato mutato.

E 'davvero la cosa giusta da fare nello scenario in cui qualcosa di terribile e sconosciuto è accaduto a continuare a mescolare quel particolare pentola e cercando di mutare lo stato che appena ha causato un'eccezione nuovo?

A volte questa sarà la cosa giusta da fare e, a volte, peggiorerà le cose. Lo scenario in cui ti trovi effettivamente dipende da cosa sta facendo esattamente il codice, quindi pensa attentamente a quale sia la cosa giusta da fare prima di scegliere ciecamente l'uno o l'altro.

Francamente, preferirei risolvere il problema non entrando nella situazione in primo luogo. Il nostro design di compilatore utilizza questo modello di progettazione e, francamente, è irritante. Nel compilatore C# esistente il meccanismo di segnalazione degli errori è "effetto collaterale". Cioè, quando parte del compilatore riceve un errore, chiama il meccanismo di segnalazione degli errori che visualizza l'errore all'utente.

Questo è un grosso problema per il binding lambda. Se si dispone di:

void M(Func<int, int> f) {} 
void M(Func<string, int> f) {} 
... 
M(x=>x.Length); 

poi il modo in cui funziona è che cerchi di associare

M((int x)=>{return x.Length;}); 

e

M((string x)=>{return x.Length;}); 

e vediamo quale, se del caso, ci dà un errore. In questo caso, il primo dà un errore, il secondo si compila senza errori, quindi questa è una conversione lambda legale e la risoluzione del sovraccarico ha esito positivo. Cosa facciamo con l'errore? Non possiamo segnalarlo all'utente perché questo programma è privo di errori!

Quindi quello che facciamo quando leghiamo il corpo di un lambda è esattamente quello che dici: diciamo al reporter di errore "non segnalare i tuoi errori all'utente, salvali in questo buffer qui invece". Quindi leghiamo il lambda, ripristiniamo il reporter di errore allo stato precedente e guardiamo il contenuto del buffer degli errori.

Potremmo evitare completamente questo problema cambiando l'analizzatore di espressioni in modo che restituisse gli errori insieme al risultato, piuttosto che commettere errori di un effetto collaterale correlato allo stato. Quindi la necessità di modificare lo stato di segnalazione degli errori scompare del tutto e non dobbiamo nemmeno preoccuparcene.

Quindi ti incoraggerei a rivisitare il tuo design. C'è un modo per rendere l'operazione che stai eseguendo non dipende dallo stato che stai mutando? Se è così, allora fallo e non devi preoccuparti di come ripristinare lo stato mutato.

(E, naturalmente, nel nostro caso abbiamo facciamo vuole ripristinare lo stato su un'eccezione. Se qualcosa all'interno del compilatore genera durante vincolante lambda, vogliamo essere in grado di riferire che per l'utente! Noi non facciamo vuoi che il reporter di errore rimanga nello stato "sopprimere gli errori di segnalazione".)

Answer 2

No , devi farlo manualmente con un blocco try/finally. Oserei dire che potrebbe scrivere un'implementazione IDisposable che farebbe qualcosa di hacky in congiunzione con le espressioni lambda, ma sospetto che un blocco try/finally sia più semplice (e non abuse the using statement).

Answer 3

No, non esiste un modo standard, è necessario implementarlo manualmente. Generic implementation of IEditableObject via TypeDescriptor and Reflection può essere utile

Answer 4

No, ma è abbastanza semplice da fare proprio questo:

bool UpdateOnTrue = true; 

// .... 

bool temp = UpdateOnTrue; 
try 
{ 
    UpdateOnTrue = false; 
    // do stuff 
} 
finally 
{ 
    UpdateOnTrue = temp; 
} 

Answer 5

Sembra che si desidera veramente

Stack<bool> 

Answer 6

in scatola ... ne dubito. Dato il vostro esempio è un semplice uso di un valore bool temporanea Sto assumendo che hai qualcosa in mente stravagante :-) È possibile implementare una sorta di Pila stucture:

1) Spingere vecchio valore sulla pila

2) Caricare il nuovo valore

3) fare cose

4) Pop dalla pila e sostituire il valore utilizzato.

ruvida (AKA testato) esempio (non può cercare la sintassi pila in questo momento)

bool CurrentValue = true; 
Stack<bool> Storage= new Stack<bool> 

Storage.Push(CurrentValue); 
CurrentValue=false; 
DoStuff(); 
CurrentValue = Storage.Pop(); 
//Continue 

Answer 7

Prova:

public void WithAssignment<T>(ref T var, T val, Action action) 
{ 
    T original = var; 
    var = val; 
    try 
    { 
     action(); 
    } 
    finally 
    { 
     var = original; 
    } 
} 

Ora si può dire:

bool flag = false; 

WithAssignment(ref flag, true,() => 
{ 
    // flag is true during this block 
}); 

// flag is false again 

Answer 8

Si dovrebbe refactoring del codice per utilizzare una funzione separata, in questo modo:

bool b = GetSomeValue(); 
DoSomething(ModifyValue(b)); 
//b still has the original value. 

Perché questo lavoro per un tipo di riferimento, è necessario copiarlo prima di scherzare con esso:

ICloneable obj = GetSomeValue(); 
DoSomething(ModifyValue(obj.Clone())); 
//obj still has the original value. 

È difficile scrivere codice corretto quando i valori delle variabili cambiano molto. Cerca di avere il minor numero possibile di riassegnazioni nel tuo codice.