Questo metodo è puro?

Ho il seguente metodo di estensione:

    public static IEnumerable<T> Apply<T>(
        [NotNull] this IEnumerable<T> source,
        [NotNull] Action<T> action)
        where T : class
    {
        source.CheckArgumentNull("source");
        action.CheckArgumentNull("action");
        return source.ApplyIterator(action);
    }

    private static IEnumerable<T> ApplyIterator<T>(this IEnumerable<T> source, Action<T> action)
        where T : class
    {
        foreach (var item in source)
        {
            action(item);
            yield return item;
        }
    }

Applica solo un'azione a ciascun elemento della sequenza prima di restituirlo.

Mi chiedevo se avrei dovuto applicare l' Pureattributo (dalle annotazioni di Resharper) a questo metodo, e posso vedere gli argomenti a favore e contro di esso.

Professionisti:

• a rigor di termini, è puro; semplicemente chiamandolo su una sequenza non altera la sequenza (restituisce una nuova sequenza) o fa qualsiasi cambiamento di stato osservabile
• chiamarlo senza usare il risultato è chiaramente un errore, dal momento che non ha alcun effetto se non viene elencata la sequenza, quindi mi piacerebbe che Resharper mi avvertisse se lo facessi.

Contro:

• anche se il Applymetodo stesso è puro, l'enumerazione della sequenza risultante comporterà cambiamenti di stato osservabili (che è il punto del metodo). Ad esempio, items.Apply(i => i.Count++)modificherà i valori degli elementi ogni volta che viene elencato. Quindi applicare l'attributo Pure è probabilmente fuorviante ...

Cosa ne pensi? Devo applicare l'attributo o no?

No, non è puro, perché ha effetti collaterali. Concretamente sta chiamando actionogni oggetto. Inoltre, non è thread-safe.

La proprietà principale delle funzioni pure è che può essere chiamata un numero qualsiasi di volte e non fa altro che restituire lo stesso valore. Non è il tuo caso. Inoltre, essere puri significa che non usi nient'altro che i parametri di input. Ciò significa che può essere chiamato da qualsiasi thread in qualsiasi momento e non causare alcun comportamento imprevisto. Ancora una volta, questo non è il caso della tua funzione.

Inoltre, potresti sbagliarti su una cosa: la purezza delle funzioni non è una questione di pro o contro. Anche un solo dubbio, che può avere effetti collaterali, è abbastanza per renderlo non puro.

Eric Lippert solleva un buon punto. Utilizzerò http://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx come parte del mio controproposto. Soprattutto linea

Un metodo puro è autorizzato a modificare oggetti che sono stati creati dopo l'entrata nel metodo puro.

Diciamo che creiamo un metodo come questo:

int Count<T>(IEnumerable<T> e)
{
    var enumerator = e.GetEnumerator();
    int count = 0;
    while (enumerator.MoveNext()) count ++;
    return count;
}

Innanzitutto, questo presuppone che GetEnumeratorsia pure (non riesco davvero a trovare alcuna fonte su questo). Se lo è, allora secondo la regola sopra, possiamo annotare questo metodo con [Pure], perché modifica solo l'istanza creata all'interno del corpo stesso. Dopodiché possiamo comporre questo e il ApplyIterator, che dovrebbe tradursi in pura funzione, giusto?

Count(ApplyIterator(source, action));

No. Questa composizione non è pura, anche se entrambe Counte ApplyIteratorsono pure. Ma potrei costruire questo argomento su premesse errate. Penso che l'idea che le istanze create all'interno del metodo siano esenti dalla regola di purezza sia sbagliata o almeno non abbastanza specifica.

Non sono d'accordo con le risposte sia di Euforico che di Robert Harvey . Assolutamente questa è una funzione pura; il problema è che

Applica solo un'azione a ciascun elemento della sequenza prima di restituirlo.

non è molto chiaro cosa significhi il primo "esso". Se "esso" significa una di quelle funzioni, allora non è giusto; nessuna di queste funzioni lo fa; lo fa MoveNextl'enumeratore della sequenza e "restituisce" l'elemento tramite la Currentproprietà, non restituendolo.

Queste sequenze sono elencate pigramente , non avidamente, quindi non è certo il caso in cui l'azione venga applicata prima che la sequenza venga restituita Apply. L'azione viene applicata dopo la restituzione della sequenza, se MoveNextviene chiamata su un enumeratore.

Come notate, queste funzioni eseguono un'azione e una sequenza e restituiscono una sequenza; l'output dipende dall'input e non vengono prodotti effetti collaterali, quindi si tratta di funzioni pure.

Ora, se si crea un enumeratore della sequenza risultante e quindi si chiama MoveNext su quell'iteratore, il metodo MoveNext non è puro, perché chiama l'azione e produce un effetto collaterale. Ma sapevamo già che MoveNext non era puro perché muta l'enumeratore!

Ora, per quanto riguarda la tua domanda, dovresti applicare l'attributo: non applicherei l'attributo perché non scriverei questo metodo in primo luogo . Se voglio applicare un'azione a una sequenza, allora scrivo

foreach(var item in sequence) action(item);

che è ben chiaro.

Non è una funzione pura, quindi applicare l'attributo Pure è fuorviante.

Le funzioni pure non modificano la collezione originale e non importa se stai passando un'azione che non ha effetto o no; è ancora una funzione impura perché il suo intento è quello di causare effetti collaterali.

Se si desidera rendere pura la funzione, copiare la raccolta in una nuova raccolta, applicare le modifiche apportate dall'azione alla nuova raccolta e restituire la nuova raccolta, lasciando invariata la raccolta originale.

Secondo me, il fatto che riceva un'azione (e non qualcosa come PureAction) non la rende pura.

E non sono nemmeno d'accordo con Eric Lippert. Ha scritto questo "() => {} è convertibile in Azione ed è una funzione pura. I suoi output dipendono esclusivamente dai suoi input e non hanno effetti collaterali osservabili".

Bene, immagina che invece di usare un delegato ApplyIterator stesse invocando un metodo chiamato Action.

Se Action è puro, anche ApplyIterator è puro. Se Action non è puro, allora ApplyIterator non può essere puro.

Considerando il tipo di delegato (non il valore dato effettivo), non abbiamo la garanzia che sarà puro, quindi il metodo si comporterà come metodo puro solo quando il delegato è puro. Quindi, per renderlo veramente puro, dovrebbe ricevere un delegato puro (e ciò esiste, possiamo dichiarare un delegato come [Puro], quindi possiamo avere una PureAction).

Spiegandolo in modo diverso, un metodo Pure dovrebbe sempre dare lo stesso risultato dati gli stessi input e non dovrebbe generare cambiamenti osservabili. A ApplyIterator può essere assegnata la stessa origine e delegato due volte ma, se il delegato sta modificando un tipo di riferimento, l'esecuzione successiva darà risultati diversi. Esempio: il delegato fa qualcosa come item.Content + = "Changed";

Quindi, usando ApplyIterator su un elenco di "contenitori di stringhe" (un oggetto con una proprietà Content di tipo stringa), potremmo avere questi valori originali:

Test

Test2

Dopo la prima esecuzione, l'elenco avrà questo:

Test Changed

Test2 Changed

E questa la terza volta:

Test Changed Changed

Test2 Changed Changed

Pertanto, stiamo modificando il contenuto dell'elenco perché il delegato non è puro e non è possibile eseguire l'ottimizzazione per evitare di eseguire la chiamata 3 volte se invocata 3 volte, poiché ogni esecuzione genererà un risultato diverso.