Чи чистий цей метод?

У мене є такий метод розширення:

    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;
        }
    }

Він просто застосовує дію до кожного елемента послідовності перед поверненням.

Мені було цікаво, чи слід застосувати Pureатрибут (від анотацій Resharper) до цього методу, і я можу побачити аргументи «за» і «проти».

Плюси:

• строго кажучи, є чистим; просто виклик його в послідовності не змінює послідовність (вона повертає нову послідовність) або не вносить будь-яких змін, що спостерігаються
• називати його без використання результату, очевидно, є помилкою, оскільки це не має ефекту, якщо не буде перерахована послідовність, тому я хотів би, щоб Решарпер попередив мене, якщо це зробити.

Мінуси:

• навіть якщо Applyсам метод чистий, перерахування отриманої послідовності буде зробити спостерігаються зміни стану (яка є точкою методи). Наприклад, items.Apply(i => i.Count++)буде змінювати значення елементів кожного разу, коли він перераховується. Тож застосування атрибута Pure, ймовірно, вводить в оману ...

Як ти гадаєш? Потрібно застосувати атрибут чи ні?

Ні, він не чистий, тому що має побічну дію. Конкретно це заклик actionдо кожного товару. Крім того, це не є безпечним для ниток.

Основна властивість чистих функцій полягає в тому, що її можна викликати будь-яку кількість разів, і вона ніколи не робить нічого іншого, ніж повертати те саме значення. Що не у вашому випадку. Крім того, будучи чистою, ви не використовуєте нічого, крім вхідних параметрів. Це означає, що його можна викликати з будь-якої потоку в будь-який час і не викликати несподіваної поведінки. Знову ж таки, це не стосується вашої функції.

Крім того, ви можете помилитися в одному: чистота функції - це не питання плюсів і мінусів. Навіть одного сумніву, що це може мати побічний ефект, достатньо, щоб зробити його не чистим.

Ерік Ліпперт піднімає хороший момент. Я буду використовувати http://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx як частину мого контр-аргументу. Особливо лінія

Чистим методом дозволяється змінювати об'єкти, створені після вступу в чистий метод.

Скажімо, ми створюємо такий метод:

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

По-перше, це передбачає, що GetEnumeratorце теж чисто (я не можу реально знайти жодного джерела про це). Якщо це так, то відповідно до вищезазначеного правила, ми можемо анотувати цей метод за допомогою [Pure], оскільки він лише модифікує екземпляр, створений в самому тілі. Після цього ми можемо скласти це і те ApplyIterator, що повинно призвести до чистої функції, правда?

Count(ApplyIterator(source, action));

Ні. Ця композиція не є чистою, навіть коли обидва Countі ApplyIteratorчисті. Але я можу будувати цей аргумент на неправильній передумові. Я думаю, що думка про те, що екземпляри, створені в рамках методу, звільнені від правила чистоти, або неправильна, або, принаймні, недостатньо конкретна.

Я не згоден з відповідями Ейфорика та Роберта Харві . Абсолютно це чиста функція; проблема в тому

Він просто застосовує дію до кожного елемента послідовності перед поверненням.

дуже незрозуміло, що означає перше "це". Якщо "це" означає одну з цих функцій, то це неправильно; жодна з цих функцій не робить цього; MoveNextз енумератора послідовності робить це, і вона «повертає» деталь через Currentвласність, не повертаючи його.

Ці послідовності перераховуються ліниво , не жадібно, тому, безумовно, не так, що дія буде застосована до повернення послідовності Apply. Дія застосовується після повернення послідовності, якщо MoveNextвикликається в перерахунку.

Як зазначаєте, ці функції виконують дію та послідовність і повертають послідовність; вихід залежить від вводу, і побічні ефекти не виробляються, тому це чисті функції ..

Тепер, якщо ви створили нумератор отриманої послідовності, а потім викликаєте MoveNext на цьому ітераторі, то метод MoveNext не є чистим, оскільки він викликає дію та створює побічний ефект. Але ми вже знали, що MoveNext не є чистим, оскільки він мутує нумератор!

Тепер, що стосується вашого питання, чи слід застосовувати атрибут: я б не застосував атрибут, тому що я не писав би цей метод в першу чергу . Якщо я хочу застосувати дію до послідовності, то я пишу

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

що добре зрозуміло.

Це не є чистою функцією, тому застосування атрибута Pure вводить в оману.

Чисті функції не змінюють оригінальну колекцію, і не має значення, чи передаєте ви дію, яка не має ефекту чи ні; це все ще нечиста функція, оскільки її мета - викликати побічні ефекти.

Якщо ви хочете зробити функцію чистою, скопіюйте колекцію в нову колекцію, застосуйте зміни, які вводить Дія до нової колекції, і поверніть нову колекцію, залишивши оригінальну колекцію незмінною.

На мою думку, той факт, що він отримує Дію (а не щось на зразок PureAction), робить її не чистою.

І я навіть не згоден з Еріком Ліппертом. Він написав це "() => {} конвертоване в Action, і це чиста функція. Виходи залежать виключно від його входів, і він не має помітних побічних ефектів".

Добре, уявіть, що замість використання делегата ApplicationIterator викликав метод з назвою Action.

Якщо дія чиста, то і ApplicationIterator чистий. Якщо дія не є чистою, то ApplicationIterator не може бути чистим.

Враховуючи тип делегата (не фактичне задане значення), ми не маємо гарантії, що він буде чистим, тому метод буде вести себе як чистий метод лише тоді, коли делегат чистий. Отже, щоб зробити його справді чистим, він повинен отримати чистого делегата (і що існує, ми можемо оголосити делегата як [Pure], щоб ми могли мати PureAction).

Пояснюючи це по-іншому, метод «Чистий» повинен завжди давати однаковий результат із однаковими входами і не повинен створювати помітних змін. ApplyIterator може бути наданий одному і тому ж джерелу і делегувати двічі, але, якщо делегат змінює тип посилання, наступне виконання дасть різні результати. Приклад: Делегат робить щось на зразок item.Content + = "Змінено";

Отже, використовуючи ApplyIterator над списком "контейнерів рядків" (об'єкт із властивістю Content типу рядка), ми можемо мати ці вихідні значення:

Test

Test2

Після першого виконання список матиме таке:

Test Changed

Test2 Changed

І це втретє:

Test Changed Changed

Test2 Changed Changed

Отже, ми змінюємо вміст списку, тому що делегат не є чистим і не може бути здійснено оптимізацію, щоб уникнути виконання виклику 3 рази, якщо викликати його 3 рази, оскільки кожне виконання призведе до іншого результату.