Re[22]: LINQ & Except
От: Ziaw Россия  
Дата: 24.06.09 11:10
Оценка: 76 (3) +1
Здравствуйте, _FRED_, Вы писали:

_FR>То есть критерием того, делать ли метод расширением является только его "чистота". Можешь ли ты согласиться с этим?


Я лично пользуюсь таким критерием: если типичный вызов метода можно повторить при этом результат окажется тот-же, и на логику это не повлияет — кандидат в IEnumerable<>.

int result;
result = seq.NullCount();
result = seq.NullCount(); // usually good

result = seq.ForEach(action);
result = seq.ForEach(action); // usually bad


У меня есть правда в проекте один ForEach для определенного типа, который является по сути SelectMany + DoAction. Тут я пошел на компромис. Хотя уже сейчас не стал так делать, а выделил бы алгоритм SelectMany делал по нему проход форичем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[2]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 10.06.09 16:27
Оценка: 26 (1) +2
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вообще касательно ForEach я потихоньку пришел к выводу, что не грех самом деле свой ForEach написать. С т.з. лаконичности кода это окупиться сто раз, к тому же часто приходится работать и с коллекциями, которые восходят к не-генерик интерфейсам — и можно сделать универсальную реализацию, которая позволит избежать лишних преобразований.


http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[8]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 11.06.09 13:02
Оценка: +3
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Спасибо, я читаю по-английски.

Видимо стоило, все-таки по русски. Ну ладно, я разжую. Аргументов там два, и оба отличаются от того, который ты нашел:

1. Речь не о том, что функционально это или нет, а о том, что вся работа с последовательностями дизайнилась в функциональном стиле, а такой метод этот стиль нарушает. Иными словами, такой вариант противоречит дизайну языка, не важно какой сам по себе дизайн, функциональный или не очень. И там подробно разжевано почему.

2. Выразительности такой код не добавит, а наоборот, запутает и, плюс к этому, "добавляет семантику замыкания, потенциально внося тонкие изменения в жизненные циклы объектов." То есть, реально, такой метод ухудшает имеющийся оператор foreach, добавляя малопредсказуемые побочные эффекты.

И при всем при этом, совершенно непонятно какую выгоду такое расширение может принести — полторы строчки кода, это не серьезно, тем более, что почти такого же эффекта можно добиться стандартными средствами.

Резюме: При кажущейся простоте, такой метод не предоставляя реальных преимуществ затрудняет понимание кода и способен привести к малопредсказуемым побочным эффектам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[3]: LINQ & Except
От: Воронков Василий Россия  
Дата: 10.06.09 16:53
Оценка: -1 :)
Здравствуйте, IB, Вы писали:

IB>http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx


Ну и что? Там высказано частное мнение, что ForEach в таком виде это вообще плохо. Основная причина, что противоречит принципам функционального программирования. Я как-то не припомню, чтобы C# стал pure functional language. Лично мне запись вида:

list.ForEach(x => DoSmth(x), x => Condition(x));


импонирует больше, чем:

foreach (var x in list)
  if (Condition(x))
    DoSmth(x);
Re[13]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 11:00
Оценка: -2
Здравствуйте, _FRED_, Вы писали:

_FR>Давайте не будем уходить в сторону абсурда, Уважаемый. Я лишь сказал Вам, что неплохо бы выкинуть нафик один из параметров Вашего метода ибо он не нужен. Учить Вас писать код и производить с Вами замены в строчках мне ни сколечки не улыбается, с SRP или без оного.


Лучше ты сам научись, как писать код, а не рассуждать о высоких материях. Посмотрел бы я на код реальных проектов, написанный с подобных позиций и на то, как хорошо он работает.
String.Replace ему не нравится видите ли, так нарушение же single responsibility — и ищем, и заменяем.
Re[10]: LINQ & Except
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 11.06.09 13:39
Оценка: +1 :)
Здравствуйте, _FRED_, Вы писали:

_FR><skipped>


_FR>3. Мне гораздо несимпатичнее отладка такого кода:

_FR>
_FR>Some1();

_FR>for(var x in yy) {
_FR>  // … сотня-другая итераций
_FR>}//fir

_FR>Some2();
_FR>

_FR>когда меня не интересуют внутренности работы цикла (требуется от Some1 перейти к Some2). Отладчик не умеет "перепрагивать" через цикл и приходится ставить специальный breakpoint к Some2(); и перепрыгивать цикл самому.

Ctrl+F10 спасут отца русской демократии И без всяких бряков
[КУ] оккупировала армия.
Re[16]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 12.06.09 17:52
Оценка: +1 -1
Здравствуйте, Воронков Василий, Вы писали:

ВВ> Хамить почему-то всегда вы начинаете,

Я!? Упаси байт, никогда! =)

ВВ>Если немножко подумать,

Василий, не надо напрягатья, за тебя уже подумали... Вдвоем — Эрик и я..

ВВ>что можно, наверное, заметить, что никакой по сути разницы между foreach и ForEach нет, кроме той самой "тонкой семантики замыкания",

О! Налицо прогресс, с пятой попытки ты таки заметил еще один аргумент, браво! =) Огорчает только то, что ты похоже так и не понял первый... Ну да ладно, давай о другом, упростим задачу.
Ну, допустим, что между foreach и ForEach, как ты утверждаешь, разницы нет. Можешь ответить на вопрос — зачем в этом случае вводить новый, нестандартый, самописный метод, когда ровно то же самое можно сдеать совершенно стандартными средствами, которыми язык оборудован с рождения, и без неприятных побочных эффектов? При том что в емкости и выразительности стандартный способ, как минимум, не проигрывает?
Твою гениальную идею запихивания туда еще и предиката оставим пока за скобками, тебе все уже объяснили, правда я боюсь, что ты опять не понял.

ВВ> И то, что у вас, извините, выражение собственного мнения, что ForEach ни в каком виде не нужен, превращается в итоге в беседу в стиле "ты дурак", "нет, сам дурак", какой-то немножко характерный показатель, не находите?

Нет, Василий, это у тебя оно превратилось в беседу в таком стиле и поэтому я нахожу, что ты бревнышка в собственном глазу не замечаешь. И этот факт вполне вписывается в твою фантастическую способность полностью игнорировать написанное, если тебе оное не нравится. И вот это я нахожу очень характерным показателем.
Мы уже победили, просто это еще не так заметно...
Re[17]: LINQ & Except
От: Аноним  
Дата: 13.06.09 13:03
Оценка: -1 :)
Здравствуйте, IB, Вы писали:

чем интересно можно себя настолько зомбировать ("эрик! преклоняюсь перед тобой о светочЪ и истина в первой инстанции" (С) IB), чтобы нести нереальную пургу выдуманную исключительно в оправдание лени/тупости/индусости разработчиков BCL в отношении ForEach?

Label:
Читай что ли по слогам (ну конечно, в яслях читать еще не умеют): ForEach метод предназначен для обработки последовательности и не имеет Н И К А К О ГО отношения к linq. Ты способен это понять? Если нет, то goto (его осилишь?) Label;

Более того, ForEach может быть своим у последовательностей разных типов. Давай, вперед, используй циклы for — они же нии%ически доступны для понимания. Задайся вопросом (ну или почитай что-нибудь кроме липпппертов на досуге), почему в С++ STL есть for_each и его крайне рекомендуют использовать а не обходить последовательности вручную!
Re[12]: LINQ & Except
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 11.06.09 14:41
Оценка: 30 (1)
Здравствуйте, _FRED_, Вы писали:

_FR>Что это за команда и как она поможет?


Debug.RunToCursor
[КУ] оккупировала армия.
Re[26]: LINQ & Except
От: Ziaw Россия  
Дата: 24.06.09 10:12
Оценка: 20 (1)
Здравствуйте, _FRED_, Вы писали:

Z>>Не стоит создавать методов расширения IEnumerable<> целью которых является получение побочных эффектов.


_FR>Чем же эта формултровка отличается от

Любой метод-расширение для IЕnumerable не должен иметь сторонних эффектов

? На мой взгляд — ничем существенным.


Тем же чем отличаются два утверждения:

1. Метод написан для получения побочных эффектов.
2. Метод не имеет 100% защиты от получения с его помощью побочных эффектов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[24]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 20:21
Оценка: 20 (1)
Здравствуйте, _FRED_, Вы писали:

_FR>Не могу одновременно понять и первое и второе:

А что здесь непонятного? Оба утверждения друг-другу не противоречат.

_FR>из первого следует (если я правильно понял твои слова), что метод расширения IEnumerable имеет право на жизнь если он приносит какую-то ещё пользу помимо совершения побочных эффектов?

Из первого следует ровно то, что там написано — extension method IEnimerable, не должен быть предназначен для получения спецэфектов.

_FR>(Кстати, ожешь показать пример метода, имеющего побочный эффект, но служащего не "только для получения" этого самого эффекта? Являются ли такими методы Debug и Watch из блога Барта?)

Тот же Any, если в качестве предиката передать в него функцию, последним оператором которой является "return true;", вырождается в ForEach, но вряд ли кому в трезвом уме и здравой памяти придет в голову так его использовать.

_FR>Но второе твоё утверждение говорит, что критерием "делать или не делать расширением является чистота", то есть отсутствие побочных эффектов

Имеется ввиду, что даже если метод не предназначен для достижения побочных эффектов, при должной ловкости рук получить их проблем не составит. При этом основные и правильные сценарии работы с этими методами, никаких побочных эффектов не предполагают, так что оба утверждения эквивалентны, просто мое более параноидально и, пожалуй, более точно.

_FR>Как это можно понять? Так "чистота" (то есть отсутствие побочных эффектов) или "ещё как-то смысл кроме побочных эффектов" должны позволять решить, делать метод расширением или не делать?

Так и понять, что критерием является именно чистота, но так как абсолютная чистота для C# (раз уж мы о нем говорим) пока вряд ли достижима, то речь идет о чистоте сценариев использования для которых этот метод предназначен.
Мы уже победили, просто это еще не так заметно...
Re[12]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.06.09 10:03
Оценка: 18 (1)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Те, которые хотят при работе с linq2sql изменения данных также делать средствами linq. Имена, явки давать?

Всё наоборот — дедушка хотел, чтобы не было бедных.
То есть как раз хочется провести чёткую границу между "ФП без побочных эффектов" и "описанием побочных эффектов".

ВВ>Хочешь я напишу реализацию, у которой будет?

Нет, не хочу.
ВВ>У ForEach<> точно так же нет состояния by design, точно так же можно написать кучу прекрасного кода, в котором никакого состояния и не будет.
Единственный смысл ForEach — получение побочных эффектов. Это понятно?

ВВ>А все потому что, как тут говорят некоторые товарищи, Aggregate<> "вносит тонкую семантику замыкания". Я вот не вижу здесь принципиальной разницы между Aggregate<> и ForEach<>.

Принципиальная разница — в том, что Aggregate остаётся ленивым. Семантика замыкания в его случае полностью оправдана — мы всё еще описываем способ получения одних данных из других. В случае ForEach мы имеем энергичную семантику "немедленно примени мне здесь побочные эффекты, которые я описал в Action<T>".

ВВ>Ты судя по всему не вполне прочитал ветку. У меня у ForEach<> тоже побочных эффектов нет.

Да ладно!
Если у него нет побочных эффектов, то его можно просто не вызывать.

ВВ>А причем здесь эти хелперы? Речь не о том, стоило ли включать ForEach<> в пространство имен Линк. Я этого вообще никогда не предлагал. Речь о том, является ли ф-ция ForEach<> абсолютным и беспрекословным злом.

Конечно же нет. Например, функция List<T>.ForEach беспрекословным злом не является. А вот хелпер для IEnumerable — является, о чём недвусмысленно написал Эрик.

ВВ>Разве Where не "добавляет семантику замыкания, потенциально внося тонкие изменения в жизненные циклы объектов"?

Нет, не добавляет. Жизненные циклы объектов, обрабатываемых в Where, изначально продлены — из-за его ленивости. Поэтому замыкание не шибко влияет на результат.
ВВ>Тебе привести пример Where с подобными эффектами?
Круче, чем у Барта, у тебя вряд ли получится
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: LINQ & Except
От: _FRED_ Черногория
Дата: 23.06.09 12:01
Оценка: 16 (1)
Здравствуйте, IB, Вы писали:

_FR>>имеет к a) Linq2Objects б) IEnumerable ц) дизайну языка C#


IB>б) Все Extension methods для IEnumerable задумывались, как не имеющие побочных эффектов.


Все имеющиеся — да сколько угодно. На счёт всех остальных — не понятно для чего.

Вот например такой артефакт имеет право на существование или нет? Как он соотносится с тем, что по твоим словам "задумывалось"?

IB>a) Все эти методы используются в Linq2Objects.


Я говорил про конкретно один мой собственный метод. Как Linq2Objects может его использовать? Можешь ли ты дать определение того, что является "Linq2Objects" что бы мы могли удостовериться, что говорим об одном и том же?

IB>c) Это все часть дизайна языка, так как Linq2Objects — часть языка.


Какого именно языка? C#? или VB? Или даже F#? а может Boo? или именно в шарпе методом ForEach пользоваться нельзя, а, например, в C++\CLI это не "затрудняет чтение и понимание"?

IB>Все вышеизложенное вместе, создает некие привычные паттерны и семантику операторов работы с множествами,


Не все множества одинаковы. И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?
Или же, специализированные множества (List<>, Array) всё-таки могут иметь свои особые "операции" ForEach, RemoveAll и т.п.?

IB>твой же библиотечный метод это все нарушает, что затрудняет чтение и понимание твоего кода.


Тут я не соглашусь, ибо семантика моего метода отлична от "всех остальных" (нету возвращаемого значения). С какой это стати операции, имеющие различные семантики нужно рассматривать вместе?
Help will always be given at Hogwarts to those who ask for it.
Re[11]: LINQ & Except
От: Аноним  
Дата: 11.06.09 10:23
Оценка: 14 (1)
Здравствуйте, Ziaw, Вы писали:

Z>Здесь вообще нет уверенности что мы идем по нему. =) linq ленив.


зачем же все утрировать, берем исходный вариант конструкции
        public static void ForEach(this IEnumerable collection, Action<object> func)
        {
            foreach (object value in collection)
                func(value);
        }


где производится операция над последовательностью, что естественно (!) и к Linq не имеет отношения.

з.ы. тогда уж обвиняйте расширяющие методы, ну никак не данный ForEach
Re[10]: LINQ & Except
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.06.09 18:30
Оценка: 14 (1)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>TestEnum() выполняется, естественно, один раз. Он формирует набор элементов, по которому осуществляет проход наш ForEach — и это второй раз.


Смешивает напитки тут кто то другой. Невозможно выполнить два прохода по данному итератору и не вызвать вывод на консоль. В принципе.

ВВ> Именно об этом я и говорил. Т.е. сначала проход по коллекции с целью выборки, затем проход по выборке с целью выполнения действия.


Там один проход.

ВВ>Что кстати в твоем примере и видно:


ВВ>[b]AVK>Action 2


Можно логику пояснить, что ты там увидел?

ВВ>А вот в случае с методом ForEach<T>(this IEnumerable<T> source, Action<T> action, Func<bool> condition) проход по коллекции будет вообще один.


Правда? Модифицируем пример:
using System;
using System.Collections.Generic;

namespace WhereForeach
{
    static class Program
    {
        static IEnumerable<int> TestEnum()
        {
            yield return 1;
            Console.WriteLine(1);
            yield return 2;
            Console.WriteLine(2);
            yield return 3;
            Console.WriteLine(3);
        }

        public static void ForEach<T>(this IEnumerable<T> source, Action<T> action, Func<T, bool> filter)
        {
            foreach (var item in source)
                if (filter(item))
                    action(item);
        }

        static void Main()
        {
            TestEnum().ForEach(i => Console.WriteLine("Action " + i), i => i == 2);
        }
    }
}

Вывод на консоль тот же. Удивительно, правда?
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[2]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 11.06.09 08:34
Оценка: 6 (1)
Здравствуйте, Sinix, Вы писали:

S>А то тут уже linq к парсингу строк прикрутить пытались.

Не знаю насчет строк, а вот впринципе парсер, довольно прикольный получился.. Но это, конечно, разминка для ума, а не продакшн код. (http://blogs.gotdotnet.ru/personal/bezzus/CommentView.aspx?guid=01b332c8-641e-4888-97ae-2de6d74aa511)
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[14]: LINQ & Except
От: Smarty Россия  
Дата: 11.06.09 15:01
Оценка: 3 (1)
Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, koandrew, Вы писали:


_FR>>>Что это за команда и как она поможет?


K>>Debug.RunToCursor


_FR>Во ё-моё, а мне казалось что эта команда заставляет отладчик перепрыгнуть к курсору


Неа... Debug.RunToCursor —

...для запуска отладчика и выполнения кода до позиции курсора


Да и вообще, зацените весь список. Может еще чего вскроется...
Re[3]: LINQ & Except
От: Smarty Россия  
Дата: 10.06.09 15:46
Оценка: +1
Здравствуйте, Tom, Вы писали:

S>>Ну поскольку какое-никакое решение уже предложено, резонно задаться вопросом — а с чем боремся, почему оно плохо? Хотим что бы быстрее+меньше кода? Что бы проще для написания? Что бы гибкость выше была? Или что?

Tom>Хочется что бы был один запрос

Не, один запрос — это тут без мазы. Вот одна строка кода — лехко, к примеру:

servicesInDatabase.Concat(servicesLocal).Except(servicesInDatabase.Intersect(servicesLocal)).ToList().ForEach(Console.WriteLine);


Но нафига ж такие извращения?? По-моему 2 строки вдвое понятнее...
Re[5]: LINQ & Except
От: Воронков Василий Россия  
Дата: 10.06.09 22:51
Оценка: :)
Здравствуйте, Lloyd, Вы писали:

ВВ>>
ВВ>>foreach (var x in list)
ВВ>>  if (Condition(x))
ВВ>>    DoSmth(x);
ВВ>>


L>А если

L>
L>foreach (var x in list.Where(Condition))DoSmth(x);
L>


Ну если оперировать теми же аргументами, что и в приведенном здесь блоге, то этот вариант практически идентичен вышеприведенному — ведь кол-во символов практически то же:

foreach (var x in list) if (Condition(x)) DoSmth(x);

foreach (var x in list.Where(Condition)) DoSmth(x);


Нет, шорт! В первом случае на один символ даже меньше

Вывод, мне кажется, каждый делает сам..
Re: LINQ & Except
От: Sinix  
Дата: 11.06.09 00:55
Оценка: +1
Здравствуйте, Tom

Tom>Вопрос, можно как то ещё упростить такой вот запрос:


Во-первых используем HashSet. Во-вторых не мешаем императивщину с функциональным стилем. То что в языке появилась ФИЧА не означает что фичу надо пихать куда попало.

А то тут уже linq к парсингу строк прикрутить пытались.
Re[3]: LINQ & Except
От: Jack128  
Дата: 11.06.09 07:53
Оценка: -1
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Воронков Василий, Вы писали:


ВВ>>Вообще касательно ForEach я потихоньку пришел к выводу, что не грех самом деле свой ForEach написать. С т.з. лаконичности кода это окупиться сто раз, к тому же часто приходится работать и с коллекциями, которые восходят к не-генерик интерфейсам — и можно сделать универсальную реализацию, которая позволит избежать лишних преобразований.


IB>http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx


А зачем тогда сделали ForEach для листа???

ЗЫ Лудше безобразно, зато единообразно.
Re[4]: LINQ & Except
От: Ziggi111 Россия  
Дата: 11.06.09 07:56
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, IB, Вы писали:




IB>>http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx

S> А синклер значит зря старается
S>http://blogs.msdn.com/ruericlippert/archive/2009/05/18/foreach-foreach.aspx
Синклеру БОЛЬШОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО!!!!!
Re[7]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 08:37
Оценка: :)
Здравствуйте, IB, Вы писали:

ВВ>>Ну если оперировать теми же аргументами, что и в приведенном здесь блоге, то этот вариант практически идентичен вышеприведенному — ведь кол-во символов практически то же:

IB>Ну, ты бы хоть по русски прочитал, если в оригинале не очень понятно, тем более, что ссылку уже дали.

Спасибо, я читаю по-английски. И никакого "послания" кроме как это "нефукционально" я там не вижу. Все остальные "недостатки" точно также применимы и для Линк.

ВВ>>Вывод, мне кажется, каждый делает сам..

IB>Угу.
Re[4]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 11.06.09 08:40
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

_FR>Мне показалось, что статья объясняет то, "почему Microsoft не предоставила для последовательностей метод расширения ForEach". Среди методов System.Linq.Enumerable.* ForEach действительно смотрелся бы странно.

Эти же аргументы подходят и для того, чтобы не делать свой extension ForEach.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[10]: LINQ & Except
От: Ziaw Россия  
Дата: 11.06.09 08:46
Оценка: -1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Селект — это не аналог foreach.


if -> Where()
точно также как и
foreach -> Select()

ВВ>А причем тут функциональный стиль?


при топике

ВВ>Вообще я не понимаю, т.е. все отписавшиеся считают, что то, что в этом блоге написано — святая истина и вопрос полностью закрыт? Тут домен блога оказывает какое-то особое воздействие или же просто сам факт, что это блог?


То, что это блог Эрика Липперта. Впрочем я не беру на веру все блоги, к данному выводу я пришел сам до чтения.

ВВ>Если я заведу блог и напишу, что нельзя использовать Where, потому что:


ВВ>1. В общем случае код не становится короче (а иногда — даже длиннее)

ВВ>2. Дебажить неудобно (а как вы будете дебажить Where(x => x == y)?)
ВВ>и прочее в том же духе.

ВВ>То вы не будете Where использовать?


Если предложите аналог заменяющий Where во всех сценариях использования можно будет обсуждать.

ВВ>Единственный аргумент там — то, что ForEach — это не функционально. Аргумент весьма своеобразный на мой взгляд. Я вот никогда не видел приложение на шарпе написанное целиком функционально. Да и в Линк при желании можно запихать побочных эффектов по самое не могу — и все будет прекрасно работать.


А я и не предлагаю писать все предложение функционально, я предлагаю не писать в функциональном стиле императивный код.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[6]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 08:47
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

_FR>>В таком виде эта запись действительно не нужна — слишком много на себя берёт.

_FR>>list.Where(Condition).ForEach(DoSmth);

ВВ>А можно обосновать этот критерий — "слишком много"?

Конечно: SRP, "Разделяй и влавствуй" и прочее и прочее — две функции, каждая из которых решает какую-то одну маленькую задачу лучше чем одна, решающая две две, что первые можно комбинировать. Вот пример — сколько у тебя сейчас перегрузок ForEach? Допустим, две:
void ForEach<T>(this IEnumerable<T>, Action<T>);
void ForEach<T>(this IEnumerable<T>, Predicate<T>, Action<T>);

Но вот у меня есть ещё варианты ForEach, передающие в Action два параметра — элемент и его индекс. Тебе, что бы этого добиться и поддржать согласованость API придётся добавить две перегрузки:
void ForEach<T>(this IEnumerable<T>, Action<T, int>);
void ForEach<T>(this IEnumerable<T>, Predicate<T>, Action<T, int>);
Help will always be given at Hogwarts to those who ask for it.
Re: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 09:17
Оценка: :)
Здравствуйте, Tom, Вы писали:

Tom>Вопрос, можно как то ещё упростить такой вот запрос:

Tom>var servicesInDatabase = new List<string>() {"s1", "s2", "s3", "s10"};
Tom>var servicesLocal = new List<string>() { "s1", "s2", "s4", "s5"};

Tom>servicesInDatabase.Except(servicesLocal).ToList().ForEach(Console.WriteLine /*Actually we'to DELETE services here*/);
Tom>servicesLocal.Except(servicesInDatabase).ToList().ForEach(Console.WriteLine /*Actually we'to CREATE services here*/);


Операции над наборами производятся разные, поэтому "объединять" наборы, ИМХО, не нужно.
".ToList()" только для ".ForEach" ИМХО, перебор — или пользоваться своим "ForEach<T>(IEnumerable<T>…" или foreach — это зависит от того, как ты трактуешь Тору…, нет, Липперта
Help will always be given at Hogwarts to those who ask for it.
Re[10]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 09:50
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

_FR>>Так как Where есть стандартный. И когда понадобится добавить что-то ещё в сигнатуру вызова, у меня и добавляется столько методов, сколько изменений требуется, а в твоём случае — приходится умножать на два.


ВВ>Хорошо, а с чем боремся-то? Сократить кол-во функций любой ценой?


Не "любой", а просто "Сократить кол-во функций".

ВВ>Так ты же говорил, что функции должны быть атомарными, что их будет много и так далее.


Что их _может быть_ много. Когда каждая выполняет строго одну задачу, мы можем справляться с необходимостью расширения функционала с посредством комбинирования. В твоём же случае и _лишним_ параметром-предикатом это приводит к дублированию.

ВВ>Потом на самом деле в моем случае придется делать перегрузки одной функции, а в твоем, если уж честно рассматривать разнообразные сценарии, двух. И преимущество опять-таки непонятно.


Как так? Давай говорить не-абстрактно: покажи сигнатуры всех твохи перегрузок ForEach? У меня их всего две (здесь
Автор: _FRED_
Дата: 11.06.09
).

ВВ>Тут основная претензия ко мне — это что я предлагаю использовать функциональный стиль для императивного кода. С чем я и не спорю. Ты же на самом деле идешь еще дальше и предлагаешь принципы написания функционального кода использовать для императивного


То, что я предлагаю называется функциональной декомпозицией и к "функциональному стилю" отношения не имеет никакого, поскольку применима в любом стиле программирования (при наличии подпрограмм).
Help will always be given at Hogwarts to those who ask for it.
Re[12]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 10:51
Оценка: -1
Здравствуйте, Воронков Василий, Вы писали:

_FR>>То, что я предлагаю называется функциональной декомпозицией и к "функциональному стилю" отношения не имеет никакого, поскольку применима в любом стиле программирования (при наличии подпрограмм).


ВВ>Да ты что? Давай тогда быть последовательными, товарищ.


Давайте не будем уходить в сторону абсурда, Уважаемый. Я лишь сказал Вам, что неплохо бы выкинуть нафик один из параметров Вашего метода ибо он не нужен. Учить Вас писать код и производить с Вами замены в строчках мне ни сколечки не улыбается, с SRP или без оного.
Help will always be given at Hogwarts to those who ask for it.
Re[13]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 14:45
Оценка: :)
Здравствуйте, koandrew, Вы писали:

_FR>>Что это за команда и как она поможет?


K>Debug.RunToCursor


Во ё-моё, а мне казалось что эта команда заставляет отладчик перепрыгнуть к курсору
Help will always be given at Hogwarts to those who ask for it.
Re[10]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 11.06.09 14:52
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

_FR>При чём здесь "дизайн языка", когда речь о библиотечном методе?

А библиотечный метод как-то в отрыве от языка существует?

_FR>Слова были о дизайне библиотеки, о том, что данные метод плохо бы смотрелся среди других методов.

Этот метот в принципе плохо смотрелся бы, если нет желания писать полноценную библиотеку методов с семантикой изменения состояния. И этот метод всегда библиотечный, даже если библиотека — это один класс из одного метода, он по сути своей хелперный.

_FR>Я вижу слова "Я философски против предоставления такого метода по двум причинам."

Какая разница предоставления кем? Я не вижу аргументов за наличие такого метода в своих библиотеках и, более того, я вижу вполне внятные аргументы против.

_FR>Я не вижу ответа в тексте блога на вопрос "почему плохо в своём коде иметь такой метод".

Аргументов в этой заметке достаточно и для моего кода.

_FR>1. никто не заставляет пользоваться замыканиями, так что данное обоснование кажется надуманным.

Никто не заставляет вообще пользоваться этим методом. Зачем мне метод с побочными эффектами, если можно обойтись без них, стандартными средствами?

_FR>2. Это вопрос самый спорный.

Наоборот, самый бесспорный =) plain foreach — чище, очевиднее и понятнее любого метода с Action<T> в качестве аргумента, я не понимаю, какие тут вообще могут быть сомнения..

_FR>когда меня не интересуют внутренности работы цикла (требуется от Some1 перейти к Some2). Отладчик не умеет "перепрагивать" через цикл и приходится ставить специальный breakpoint к Some2();

_FR>и перепрыгивать цикл самому.
Поставить дополнительный breakpoint — это один клик мышкой, при том, что весь код перед глазами. А вот когда проблемы на какой-то из итераций — все гораздо веселее.

_FR>Использование одной строчки там, где в другом случае нужно много больше.

Не много, а ровно на одну — я уже писал, что этот аргумент вообще несерьезный.

_FR>Для стандартной библиотеки — да.

Для нестандартной тоже. Другие аргументы, кроме числа строк кода есть?

_FR>Мне кажется, что этих эффектом можно добиться и без ForEach.

И с каких пор возможность прострелить себе ногу, стала аргументом в пользу того, чтобы еще и давать себе повеситься?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[10]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 11.06.09 14:52
Оценка: -1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Знаешь, "по-русски" я бы тебе давно уже объяснил, что я думаю о подобных гайдлайнах — да боюсь забанят.

С тобой-то давно ясно, что закон тебе не писан.. Ну да кто ж тебе доктор?

ВВ>А в данном случае непонятно — откуда возникает требование этого функционального стиля?

Родной, это не требование, это дизайн такой. Расширяющие методы работы с коллекциями, не меняют состояния коллекций.
Если хочешь изменить — есть другие средства. Меняя такое положение дел, ты нарушаешь привычную логику, чем затрудняешь понимание твоего кода.

ВВ>Если передо мной стоят задачи модификации

Ты не знаешь как их решить, без ForEach?

ВВ>или, не дай бог, появляются методы имеющие сохраняемое состояние — то причем здесь вообще функциональный стиль?

А почему ты здесь функциональный стиль вспомнил?
У тебя очевидный пробел в логике, смотри: Дизайн операторов на последовательностях != вообще вся работа с последовательностями. Если тебе нужно последовательности менять, то в чем проблема использовать стандартный подход, вместо того, чтобы пытаться применить инструмент не по делу?
Никто не запрещает менять последовательность — не рекомендуют это делать с помощю средств для этого не предназначеных, что вообщем логично.

ВВ> И почему это должно быть функционально, если в действительности это не функционально ни на йоту?

Что именно не функционально?

ВВ>Это мы только ForEach<> касаемся, а можно еще и рассмотреть всякие Aggregate<> — там ведь вообще ужас с этой точки зрения.

Ты точно понял, что написал?

ВВ>String.Replace — очень схожая задача с обсуждаемой здесь.

Нет, не схожая, нужно объяснять почему?

ВВ> И совершенно нефункционально.

Функционально на 100%, нужно объяснять почему?

ВВ>Дизайну Шарпа противоречит императивный стиль?

Руководствуясь какой логикой ты такой вывод сделал?

ВВ>Функциональному дизайну Линка, который здесь вообще не причем, противоречит императивный стиль?

Ну и зачем ты его вспомнил, если он непричем?

ВВ>То же самое можно сказать и про Where по сравнению с foreach.

Нельзя, нужно объяснять почему?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[11]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 15:02
Оценка: :)
Здравствуйте, IB, Вы писали:

ВВ>>Знаешь, "по-русски" я бы тебе давно уже объяснил, что я думаю о подобных гайдлайнах — да боюсь забанят.

IB>С тобой-то давно ясно, что закон тебе не писан.. Ну да кто ж тебе доктор?

Мне с тобой тоже все ясно. Рад, что хотя бы здесь у нас полный консенсус.

ВВ>>А в данном случае непонятно — откуда возникает требование этого функционального стиля?

IB>Родной, это не требование, это дизайн такой. Расширяющие методы работы с коллекциями, не меняют состояния коллекций.

Я где-то меняю состояние коллекции?

ВВ>>или, не дай бог, появляются методы имеющие сохраняемое состояние — то причем здесь вообще функциональный стиль?

IB>А почему ты здесь функциональный стиль вспомнил?
IB>У тебя очевидный пробел в логике, смотри: Дизайн операторов на последовательностях != вообще вся работа с последовательностями. Если тебе нужно последовательности менять, то в чем проблема использовать стандартный подход, вместо того, чтобы пытаться применить инструмент не по делу?

Тебе видимо разжевать нужно?
ОК. Я инструмент не по делу не применяю, свой инструмент можешь оставить при себе, я использую экстешин ForEach, который:
а) не несет в себе ничего функционального
б) не имеет никакого отношения к Линку
Так яснее?

ВВ>>Это мы только ForEach<> касаемся, а можно еще и рассмотреть всякие Aggregate<> — там ведь вообще ужас с этой точки зрения.

IB>Ты точно понял, что написал?

А ты точно прочитал? Если с первого раза не получилось, попробуй повторно.

ВВ>>String.Replace — очень схожая задача с обсуждаемой здесь.

IB>Нет, не схожая, нужно объяснять почему?
ВВ>>То же самое можно сказать и про Where по сравнению с foreach.
IB>Нельзя, нужно объяснять почему?

Объясни этому кому-нибудь другому. На сегодня я от тебя уже бреда наслушался.
Re[12]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 12.06.09 14:08
Оценка: -1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я где-то меняю состояние коллекции?

Конечно. Ты же тут начал разоряться про изменения. =)

ВВ>Тебе видимо разжевать нужно?

Васенька, родной, для начала лучше сам постарайся понять о чем ты, хотя бы для себя, так правда будет лучше.

ВВ>ОК. Я инструмент не по делу не применяю,

Ты именно это и делаешь

ВВ>, я использую экстешин ForEach, который:

ВВ>а) не несет в себе ничего функционального
ВВ>б) не имеет никакого отношения к Линку
ВВ>Так яснее?
Ну, это ты у себя должен спросить. Это у тебя идиосинкразия на слово "функциональный" настолько сильная, что ты даже контекста не отслеживаешь, и про LINQ тут только ты говоришь. Вот и разберись, о чем это ты.. )
Ну и попробуй все-таки внимательно почитать, что тебе пишут, без нервов и истерик.

ВВ>А ты точно прочитал?

Да, Василий, в отличии от тебя, я это сделал..

ВВ>Объясни этому кому-нибудь другому. На сегодня я от тебя уже бреда наслушался.

Зря, возможно чему-нибудь научился бы и перестал бы пургу нести.. Хотя, с другой стороны, если я правильно помню, ты еще ООП не освоил, так что за функциональщину тебе пожалуй действительно рано браться..
Мы уже победили, просто это еще не так заметно...
Re[13]: LINQ & Except
От: Воронков Василий Россия  
Дата: 12.06.09 14:18
Оценка: :)
Здравствуйте, IB, Вы писали:

ВВ>>Объясни этому кому-нибудь другому. На сегодня я от тебя уже бреда наслушался.

IB>Зря, возможно чему-нибудь научился бы и перестал бы пургу нести.. Хотя, с другой стороны, если я правильно помню, ты еще ООП не освоил, так что за функциональщину тебе пожалуй действительно рано браться..

Вас видимо сильно мучают на работе, раз возникает желание с таким компентеным видом вдалбливать всем "пургу". Что ж, сочувствую. Попробуйте чаще использовать мозг — может, и жизнь тогда наладится.
Re[3]: LINQ & Except
От: Sinix  
Дата: 14.06.09 03:58
Оценка: -1
Здравствуйте, Аноним

А>А зачем? Except внутри и сам использует Set (который hash):


Гммм... имхо проще явно сказать что ты хочещь, используя set, чем дёргать его же через дополнительный слой абстракции. Коряво.
Re[3]: LINQ & Except
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.06.09 18:25
Оценка: +1
Здравствуйте, IB, Вы писали:

IB>http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx


В дополнение — при замене нормального foreach на метод ForEach, в решарпере, по очевидным причинам, отвалится целая пачка рефакторингов и квикфиксов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[14]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.06.09 10:57
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

_FR>Вот ещё один толкователь Мужики, вы понятным языком можете рассказать, что и где вы там видите или сами понимаете?


_FR>Ключевой смысл, я полагаю, имеет предложение

_FR>

Мне как-то не нравится идея сделать единственный оператор для последовательностей, который полезен только для спецэффектов.

_FR>Но что в этом плохого?
В том, что он будет единственным. Это нарушает вселенскую симметрию linq2objects.
В классе List<T> дохрена методов, рассчитанных на побочные эффекты, поэтому там (как и в Array) ForEach уместен. Для IEnumerable он будет слишком неожиданным.

_FR>Методов, имеющих своей целью создание побочных эффектов множество.

В Linq2Objects таких методов нет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 23.06.09 11:25
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Такой способ применения позволяет обойтись без введения временной переменной, весь смысл которой — дотащить текущий элемент до вызова.

Нивапрос
public static void Main(string args[])
{
  SinclairLib.ForEach(args, Console.WriteLine);
}
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[17]: LINQ & Except
От: Аноним  
Дата: 23.06.09 11:42
Оценка: +1
Здравствуйте, IB, Вы писали:

IB>б) Все Extension methods для IEnumerable задумывались, как не имеющие побочных эффектов.

IB>a) Все эти методы используются в Linq2Objects.
IB>c) Это все часть дизайна языка, так как Linq2Objects — часть языка.
IB>Все вышеизложенное вместе, создает некие привычные паттерны и семантику операторов работы с множествами, твой же библиотечный метод это все нарушает, что затрудняет чтение и понимание твоего кода.

так всетаки дело в том, что он метод ForEach расширяющий?
ок, чем плох тот же самый метод но в виде простой статической функции? почему все кто "читал липерта" навязывают оператор foreach?
Re[19]: LINQ & Except
От: Аноним  
Дата: 24.06.09 08:58
Оценка: :)
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, <Аноним>, Вы писали:


А>>так всетаки дело в том, что он метод ForEach расширяющий?

IB>Именно, Василий.. =)
я не Василий , но ты можешь звать меня Хозяин (с большой буквы пожалуйста)

IB>Ну, например тем, что он совершенно бесполезен, и опять-таки ясности коду не добавит, если он имеет ту же семантику обычного foreach. Скажем, против метода Parallel.ForEach<T> — вообще никаких возражений нет — сразу видно, что это ни разу не обычный foreach, со своей логикой, которая, к тому же, очевидна из названия класса.


IB>Почему-то им не пришло в голову делать extension method ParallelForEach<T>(this IEnumerable...)

пример некорректен. потому что это принципиально другой foreach. именно поэтому он у них в своем статическом классе название которого отражает суть обработки.
семантика расширяющего метода кроме прочего заключается в видимости "собственного" ForEach у разных последовательностей, особая обработка которых может быть инкапсулированна в этом методе.

IB>С чего ты взял, что кто-то чего-то навязывает?

читай ветку внимательно
Re[22]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 09:38
Оценка: -1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Т.е., несмотря ни на что, я тебе все равно являюсь под образом анонима?

Стиль похож, не вижу смысла различать..
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[18]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 09:38
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Так что все просто. Обычный ForEach:


ВВ>
ВВ>static IEnumerable<Int32> ForEach(this IEnumerable<Int32> self, Func<Int32,Boolean> cond, Action<Int32> act)
ВВ>{
ВВ>    foreach (var i in self)
ВВ>        if (condition(i))
ВВ>            action(i);
ВВ>}
ВВ>

Это не будет компилироваться. Ты, наверное, имел в виду static void?
ВВ>Ленивый ForEach:
ВВ>
ВВ>static IEnumerable<Int32> ForEach(this IEnumerable<Int32> self, Func<Int32,Boolean> cond, Action<Int32> act)
ВВ>{
ВВ>  foreach (var i in self)
ВВ>     if (condition(i))
ВВ>     {
ВВ>       action(i);
ВВ>       yield return i;
ВВ>     }
ВВ>}
ВВ>

Ок, хорошо. А что насчёт else? А почему сначала action, а потом yield return i?

ВВ>А это ты уже сам проверь

Что значит "сам проверь"??? Я не хочу читать код, в котором куда ни ткни — везде "сам проверь"!
Без обращения к исходникам невозможно догадаться, будет ли yield делаться перед action или после. Из-за этого могут случиться совершенно произвольные комбинации побочных эффектов.
ВВ>
ВВ>var it = arr.ForEach(i => i < 2, Console.WriteLine).ForEach(i => i < 3, Console.WriteLine);
ВВ>

А можно какой-нибудь более реалистичный пример?
И, желательно, законченный — в том смысле, чтобы было видно, в какой именно момент всё таки вызываются итераторы. Я имею в виду — что ты собираешься делать дальше с этим it? Как ты будешь его применять? Что можно сделать с ним полезного, кроме как тупо зафигачить foreach?

ВВ>Кстати, раз уж зашел такой разговор, объясни мне теперь как ты себе представляешь себе ленивой функцию:


ВВ>
ВВ>T Aggregate<T>(this IEnumerable<T> self, Func<T,T,T> func);
ВВ>

ВВ>Очень интересно будет послушать

Представляю себе примерно вот такой:
Func<T> Aggregate<T> (this IEnumerable<T> self, Func<T, T, T> aggregate)

Тело сам угадаешь, или надо написать?

ВВ>Согласен

ВВ>Суть-то конечно не в том, чтобы ForEach превращать в ленивую чистую и светлую функцию. Ленивая — ну может иногда это имеет смысл. Чистая — ну может практически никогда Ну и что с того? Вот вернемся к Aggregate. У меня половина использований этой ф-ции может иметь побочные эффекты. А знаешь почему? Потому что 1) агрегаты сложные, может быть несколько аккумуляторов, сложное состояние
Да. Но основная цель Aggregate — всё-таки не побочные эффекты, а таки вычисление результата. Более того, скорее всего окажется, что в реальном проекте ты сам постараешься свести побочные эффекты к минимуму — потому, что скармливание чистых функций в Aggregate, к примеру, позволит безопасно раскидать его по нескольким ядрам.

ВВ>2) побочные эффекты с замыканиями получить легко и удобно, ага. Потому что лямбды при всей своей как бы "функциональности" на самом деле деле таят в себе грубую и жестокую императивщину — независимо от того, из одного ли или нескольких экспрешионов они состоят. Ну например:

ВВ>
ВВ>int y = 0;            
ВВ>Func<Int32,Int32> f = x => y += x;
ВВ>

Это всё, конечно же, понятно. Ну, кроме того, что

ВВ>Ведь не убрали же "тонкую семантику замыкания" из лямбд почему-то. А это значит, что любая функция, принимающая замыкания, потенциально может иметь побочные эффекты. Тчк. И ForEach тут не исключение. Он просто... ну "чуть больше" склоняет нас к тому, чтобы сотворить побочные эффекты, чем тот же Aggregate.

"чуть больше" — это, должно быть, шутка. Приведи мне пример реального аргумента, который ты бы скормил в ForEach в реальном проекте, и чтобы он не имел побочных эффектов. Ок, выброс исключения мы побочными эффектами считать не станем.

ВВ>Но это даже и неважно. Пусть ForEach у нас целиком "побочный" и неленивый. Ты объясни мне, что в этой функции такого, что надо с пеной у рта и кулаками доказывать, что она не нужна, вносит там всякое непонятно что и вообще зло в чистом виде, а? Липерт, которого ты переводил, написал, повторюсь:


ВВ>1. В библиотеке System.Core этой функции нет и нечего ей там делать (с чем я абсолютно согласен).

ВВ>2. Ему лично *с философской точки зрения* эта функция не нравится, но если вам нравится — напишите ее сами.
Ок.
ВВ>Все. После этого некоторые товарищи решили это самое "философское не нравится" превратить в какую-то догму.
А мне показалось, что некоторые товарищи попытались выяснить, чем именно Эрику не нравится эта функция с философской точки зрения. .
Я как бы тоже не стану бегать за вами с бензопилой и проверять, нет ли у вас там форича для IEnumerable.

ВВ>А нафига? Мнение Липерта закон? Странно вот получается, на Фаулера с Эвансом вам насрать, а Липерт — уже икона.

Ничего странного. Фаулер пишет пургу, а Липперт — рулит. Тут как бы не личность первична, а её плоды.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: LINQ & Except
От: Ziaw Россия  
Дата: 24.06.09 09:52
Оценка: +1
Здравствуйте, _FRED_, Вы писали:


_FR>Скажи один раз — точна ли и полна ли такая формулировка:

_FR>

Любой метод-расширение для IЕnumerable не должен иметь сторонних эффектов


Не точна, т.к. замыкания позволяют создавать побочные эффекты очень легко. Но это не повод писать методы единственной целью которых является создание побочных эффектов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[24]: LINQ & Except
От: Ziaw Россия  
Дата: 24.06.09 10:07
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

_FR>Будь добр, приведи точную формулировку.


Это же не уголовный кодекс, это рекомендация. Не стоит создавать методов расширения IEnumerable<> целью которых является получение побочных эффектов. Это полезно как присвоение идентификаторам говорящих имен, и почти также как объявление readonly, const и private. Если не следовать этим правилам код будет работать точно также, но сопровождаться намного дороже.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[22]: LINQ & Except
От: Ziaw Россия  
Дата: 24.06.09 10:53
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вот пример "чистого" ForEach:


ВВ>
ВВ>cargo.ForEach(c => c.WeightLimited && c.Weight > LIMIT, c => ThrowException(c.UniqueId, c.Weight));
ВВ>



по мне — вот такой код будет гораздо проще понимать и рефакторить и он безусловно чище.

            var wrongCargo = cargo.FirstOrDefault(c => c.WeightLimited && c.Weight > LIMIT);

            if (wrongCargo != null)
                ThrowException(wrongCargo.UniqueId, wrongCargo.Weight));
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[24]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 03:50
Оценка: :)
Здравствуйте, _FRED_, Вы писали:

_FR>(Кстати, ожешь показать пример метода, имеющего побочный эффект, но служащего не "только для получения" этого самого эффекта? Являются ли такими методы Debug и Watch из блога Барта?)

Как нефиг делать:
    int[] a = new[] {1, 2, 4, 5, 7, 8, 9};
    int t = 0;
    var w = 6;
    var rucksack = a.Where(x => (t += x) <= w);

Как говорил другой Барт, "I didn't think it was physically possible, but this both sucks and blows."
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: LINQ & Except
От: Воронков Василий Россия  
Дата: 26.06.09 15:32
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

ВВ>>Поменяй местами yield и action и твой код просто перестанет работать:

ВВ>>it.GetEnumerator().MoveNext();
ВВ>>- а дальше не пошли. Результат: action не вызван.
S>Это твой код перестанет работать. А мой код, быть может, наоборот хочет уметь прерывать выполнение action до того, как он произойдёт.

Ага, именно для этого как раз и существует condition.

ВВ>>Ты уж извини, но если немножко подумать, то можно.

S>Ты уж извини, но как видно, думать надо много.

А ты постарайся, думать это полезно.

ВВ>>Так что да, если тебе непонятно, то сам и проверяй:

ВВ>>
ВВ>>var arr = new int[]{ 1, 1, 1, 2, 2, 2, 3, 3, 3};            
ВВ>>var it = arr.ForEach(i => i < 2, Console.WriteLine).ForEach(i => i < 3, Console.WriteLine);
ВВ>>

S>Дальше что? Этот код ничего не делает. На всякий случай намекну, что в нём нет ни одного вызова GetEnumerator().

Ну уж извини, я-то думал, что ты сам сможешь вызов итератора написать. Видимо, заблуждался. Вот тебе полный код:

using System;
using System.Linq;
using System.Collections.Generic;

class Program
{
    static void Main()
    {
        var arr = new int[]{ 1, 1, 1, 2, 2, 2, 3, 3, 3};            
        var it = arr.ForEach(i => i < 2, Console.WriteLine).ForEach(i => i < 3, Console.WriteLine);
        
        foreach (var v in it)
        {}
    }
}

static class Iterator
{
    public static IEnumerable<T> ForEach<T>(this IEnumerable<T> self, Func<T,Boolean> condition, Action<T> action)
    {
        foreach (var v in self)
            if (condition(v))
            {
                action(v);
                yield return v;
            }
    }
}


На всякий случай уточню, что код "сам по себе" тоже ничего не делает, сначала скомпилировать надо.

S>Кроме того, это вырожденный пример — ясно, что в нём от порядка ничего не зависит, т.к. ты вызываешь две взаимно коммутативные операции.


О, вот видишь. От порядка ничего не зависит. Значит, тебе и правда очень полезно все скомпилировать и посмотреть результат.

S>Кстати, ты сам-то сможешь сказать, не запуская программу что произойдёт, если добавить третью строчку? Сколько и чего будет выведено на консоль?


Это тебе домашнее задание будет

ВВ>>Я тебе дал пример — действие нужно выполнять *пошагово*. Мы не знаем — нужно ли нам проходить по всей последовательности. Пользователь жамкнет Next, пойдем дальше. Нет, так нет.

S>Ты, наверное, не понимаешь, что такое "конкретный пример". Пример "есть какое-то действие, которое нужно выполнять по какому-то условию" — абстрактный.
S>Ок, пусть у нас будет, к примеру, замена подстрок в тексте. Мы хотим перед заменой спросить у человека, надо ли заменять. Твой форич не делает того, чего нужно, потому что он будет сначала заменять, а потом — спрашивать.

Мой форич сначала спрашивает — condition, а потом заменяет — action.

ВВ>>А куда стандартная делась?

S>Ты меня спросил, как я себе представляю ленивый Aggregate — я ответил. Я не виноват, что моя фантазия побогаче.

Да уж, я в твоей фантазии не сомневаюсь, раз ты стандартный Aggregate в ленивые функции записал.

ВВ>>Основная цель ForEach — выполнить действие. Действие может иметь побочные эффекты.

S>Гм. Действие — и есть побочные эффекты. Действие без побочных эффектов = это хлопок одной ладонью.

Слушай, раз у тебя такая богатая фантазия и глубокие познания в области ФП, неужели сам не можешь придумать чистую функцию без возвращаемого значения, которая к тому же делает что-то полезное?
Вот тебе подсказочки:

Continuation passing style

ВВ>>Да, пусть вероятность наличия побочных эффектов в данном действии 99 к 1 — но мы же не вероятность обсуждаем, а дизайн?

S>Дело не в вероятности. Вероятность отсутствия побочных эффектов здесь =0.
ВВ>>Пример "чистого" ForEach — валидация последовательности: элементы последовательности должны удовлетворять некоторому условию, если не удовлетворяют — генерируем исключение.
S>Многословный и малопонятный способ записать

Все, что ты пишешь здесь — это "многословный и малопонятный способ записать" — мне нравится ForEach<>, и я не могу объяснить, почему
Re[26]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 27.06.09 10:30
Оценка: :)
Здравствуйте, _FRED_, Вы писали:

_FR>Спасибо, наконец-то дошло. Тогда такой вопрос: cледующий метод будет "идеалогически верным" или нет?

На мой взгляд нет.
Мы уже победили, просто это еще не так заметно...
LINQ & Except
От: Tom Россия http://www.RSDN.ru
Дата: 10.06.09 13:13
Оценка:
Всем привет,

Вопрос, можно как то ещё упростить такой вот запрос:

var servicesInDatabase = new List<string>() {"s1", "s2", "s3", "s10"};
var servicesLocal = new List<string>() { "s1", "s2", "s4", "s5"};

servicesInDatabase.Except(servicesLocal).ToList().ForEach(Console.WriteLine /*Actually we'to DELETE services here*/);
servicesLocal.Except(servicesInDatabase).ToList().ForEach(Console.WriteLine /*Actually we'to CREATE services here*/);
Народная мудрось
всем все никому ничего(с).
Re: LINQ & Except
От: Tom Россия http://www.RSDN.ru
Дата: 10.06.09 13:18
Оценка:
Собственно вопрос в том, можно ли обьединить два запроса в один, и будет ли это понятнее
Народная мудрось
всем все никому ничего(с).
Re: LINQ & Except
От: Smarty Россия  
Дата: 10.06.09 13:23
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>Всем привет,


Tom>Вопрос, можно как то ещё упростить такой вот запрос:


Tom>
Tom>var servicesInDatabase = new List<string>() {"s1", "s2", "s3", "s10"};
Tom>var servicesLocal = new List<string>() { "s1", "s2", "s4", "s5"};

Tom>servicesInDatabase.Except(servicesLocal).ToList().ForEach(Console.WriteLine /*Actually we'to DELETE services here*/);
Tom>servicesLocal.Except(servicesInDatabase).ToList().ForEach(Console.WriteLine /*Actually we'to CREATE services here*/);

Tom>


Ну поскольку какое-никакое решение уже предложено, резонно задаться вопросом — а с чем боремся, почему оно плохо? Хотим что бы быстрее+меньше кода? Что бы проще для написания? Что бы гибкость выше была? Или что?
Re[2]: LINQ & Except
От: Tom Россия http://www.RSDN.ru
Дата: 10.06.09 14:27
Оценка:
S>Ну поскольку какое-никакое решение уже предложено, резонно задаться вопросом — а с чем боремся, почему оно плохо? Хотим что бы быстрее+меньше кода? Что бы проще для написания? Что бы гибкость выше была? Или что?
Хочется что бы был один запрос
Народная мудрось
всем все никому ничего(с).
Re[3]: LINQ & Except
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 15:04
Оценка:
Здравствуйте, Tom, Вы писали:
Tom>Хочется что бы был один запрос
Странно, что Симметрической разности над множествами нет, достаточно просто реализуемая при сравнении сортрованных множеств.
и солнце б утром не вставало, когда бы не было меня
Re: LINQ & Except
От: Воронков Василий Россия  
Дата: 10.06.09 15:13
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>
Tom>var servicesInDatabase = new List<string>() {"s1", "s2", "s3", "s10"};
Tom>var servicesLocal = new List<string>() { "s1", "s2", "s4", "s5"};

Tom>servicesInDatabase.Except(servicesLocal).ToList().ForEach(Console.WriteLine /*Actually we'to DELETE services here*/);
Tom>servicesLocal.Except(servicesInDatabase).ToList().ForEach(Console.WriteLine /*Actually we'to CREATE services here*/);
Tom>


Вообще касательно ForEach я потихоньку пришел к выводу, что не грех самом деле свой ForEach написать. С т.з. лаконичности кода это окупиться сто раз, к тому же часто приходится работать и с коллекциями, которые восходят к не-генерик интерфейсам — и можно сделать универсальную реализацию, которая позволит избежать лишних преобразований.
Re[3]: LINQ & Except
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 16:32
Оценка:
Здравствуйте, IB, Вы писали:



IB>http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx

А синклер значит зря старается
http://blogs.msdn.com/ruericlippert/archive/2009/05/18/foreach-foreach.aspx
и солнце б утром не вставало, когда бы не было меня
Re[4]: LINQ & Except
От: Lloyd Россия  
Дата: 10.06.09 21:29
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>импонирует больше, чем:


ВВ>
ВВ>foreach (var x in list)
ВВ>  if (Condition(x))
ВВ>    DoSmth(x);
ВВ>


А если
foreach (var x in list.Where(Condition))DoSmth(x);
Re[4]: LINQ & Except
От: Ziaw Россия  
Дата: 11.06.09 05:12
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

Чтобы понять код:

ВВ>
ВВ>list.ForEach(x => DoSmth(x), x => Condition(x));
ВВ>


надо знать внутреннюю реализацию ForEach, судя по эквивалентному коду она не интуитивна.

ВВ>
ВВ>foreach (var x in list)
ВВ>  if (Condition(x))
ВВ>    DoSmth(x);
ВВ>


Если же в ForEach оставить только экшен — у него не останется преимуществ перед foreach.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[5]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 07:52
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>надо знать внутреннюю реализацию ForEach, судя по эквивалентному коду она не интуитивна.


У вас какая-то избирательная интуиция. Where(condition) — интуитивно-понятно, а ForEach(action, condition) — нет.

ВВ>>
ВВ>>foreach (var x in list)
ВВ>>  if (Condition(x))
ВВ>>    DoSmth(x);
ВВ>>


Z>Если же в ForEach оставить только экшен — у него не останется преимуществ перед foreach.


Почему? Кода меньше не становится?
Re[6]: LINQ & Except
От: Ziaw Россия  
Дата: 11.06.09 07:56
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Почему? Кода меньше не становится?


А какие еще преимущества у такой записи?
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[4]: LINQ & Except
От: Ziggi111 Россия  
Дата: 11.06.09 07:59
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, IB, Вы писали:


IB>>http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx


ВВ>Ну и что? Там высказано частное мнение, что ForEach в таком виде это вообще плохо. Основная причина, что противоречит принципам функционального программирования. Я как-то не припомню, чтобы C# стал pure functional language. Лично мне запись вида:


ВВ>
ВВ>list.ForEach(x => DoSmth(x), x => Condition(x));
ВВ>


ВВ>импонирует больше, чем:


ВВ>
ВВ>foreach (var x in list)
ВВ>  if (Condition(x))
ВВ>    DoSmth(x);
ВВ>


ИМХО
list.ForEach(x => DoSmth(x), x => Condition(x));

читается не лучше, но, как и сказано в указанном блоге, недебагебелбно
Re[7]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 08:11
Оценка:
Здравствуйте, Ziaw, Вы писали:

ВВ>>Почему? Кода меньше не становится?

Z>А какие еще преимущества у такой записи?

Я уже говорил — тут каждый выводы делает сам

На мой взгляд преимущество тут точно такое же как и у простого Where(x => Condition(x)) перед if (Condition(x)) {} — когда "букаф" даже больше получается.

Ну и давайте вспомним такую штуку как однообразность кода. Если я в одном месте использую ForEach, то и в другом, в аналогичной ситуации, хотелось бы тоже.
Re[5]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 08:12
Оценка:
Здравствуйте, Ziggi111, Вы писали:

Z>ИМХО

Z>
Z>list.ForEach(x => DoSmth(x), x => Condition(x));
Z>

Z>читается не лучше, но, как и сказано в указанном блоге, недебагебелбно

Это в блоге "недебагебелбно" У меня-то все дебагебельно — код в соседней сборке лежит
Re[8]: LINQ & Except
От: Ziaw Россия  
Дата: 11.06.09 08:17
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>На мой взгляд преимущество тут точно такое же как и у простого Where(x => Condition(x)) перед if (Condition(x)) {} — когда "букаф" даже больше получается.


В отличии от ForEach/foreach они не эквивалентны. Для функцифонального стиля уже есть аналог foreach, это Select(). Все что выходит за рамки селекта почти наверняка будет нести побочные эффекты и придавать этому вид функции означает запутать читателя.

ВВ>Ну и давайте вспомним такую штуку как однообразность кода. Если я в одном месте использую ForEach, то и в другом, в аналогичной ситуации, хотелось бы тоже.


В каком месте?
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[4]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 08:23
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

IB>>http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx


ВВ>Ну и что? Там высказано частное мнение, что ForEach в таком виде это вообще плохо. Основная причина, что противоречит принципам функционального программирования. Я как-то не припомню, чтобы C# стал pure functional language. Лично мне запись вида:


ВВ>list.ForEach(x => DoSmth(x), x => Condition(x));


В таком виде эта запись действительно не нужна — слишком много на себя берёт.
list.Where(x => Condition(x)).ForEach(x => DoSmth(x));

или вообще так:
list.Where(Condition).ForEach(DoSmth);
Help will always be given at Hogwarts to those who ask for it.
Re[9]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 08:25
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>В отличии от ForEach/foreach они не эквивалентны. Для функцифонального стиля уже есть аналог foreach, это Select().


Селект — это не аналог foreach.

Z>Все что выходит за рамки селекта почти наверняка будет нести побочные эффекты и придавать этому вид функции означает запутать читателя.


А причем тут функциональный стиль?

ВВ>>Ну и давайте вспомним такую штуку как однообразность кода. Если я в одном месте использую ForEach, то и в другом, в аналогичной ситуации, хотелось бы тоже.

Z>В каком месте?

В одном у меня есть кондишин, в другом — нет.

Вообще я не понимаю, т.е. все отписавшиеся считают, что то, что в этом блоге написано — святая истина и вопрос полностью закрыт? Тут домен блога оказывает какое-то особое воздействие или же просто сам факт, что это блог? Если я заведу блог и напишу, что нельзя использовать Where, потому что:

1. В общем случае код не становится короче (а иногда — даже длиннее)
2. Дебажить неудобно (а как вы будете дебажить Where(x => x == y)?)
и прочее в том же духе.

То вы не будете Where использовать?

Единственный аргумент там — то, что ForEach — это не функционально. Аргумент весьма своеобразный на мой взгляд. Я вот никогда не видел приложение на шарпе написанное целиком функционально. Да и в Линк при желании можно запихать побочных эффектов по самое не могу — и все будет прекрасно работать.

Может, в таком случае выбор языке не совсем правильный?
Re[3]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 08:27
Оценка:
Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Воронков Василий, Вы писали:


ВВ>>Вообще касательно ForEach я потихоньку пришел к выводу, что не грех самом деле свой ForEach написать. С т.з. лаконичности кода это окупиться сто раз, к тому же часто приходится работать и с коллекциями, которые восходят к не-генерик интерфейсам — и можно сделать универсальную реализацию, которая позволит избежать лишних преобразований.


IB>http://blogs.msdn.com/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx


Мне показалось, что статья объясняет то, "почему Microsoft не предоставила для последовательностей метод расширения ForEach". Среди методов System.Linq.Enumerable.* ForEach действительно смотрелся бы странно.
Help will always be given at Hogwarts to those who ask for it.
Re[6]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 11.06.09 08:34
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну если оперировать теми же аргументами, что и в приведенном здесь блоге, то этот вариант практически идентичен вышеприведенному — ведь кол-во символов практически то же:

Ну, ты бы хоть по русски прочитал, если в оригинале не очень понятно, тем более, что ссылку уже дали.
Действительно, зря что ли Синклер старался? http://blogs.msdn.com/ruericlippert/archive/2009/05/18/foreach-foreach.aspx

ВВ>Вывод, мне кажется, каждый делает сам..

Угу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[5]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 08:35
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>В таком виде эта запись действительно не нужна — слишком много на себя берёт.

_FR>
_FR>list.Where(Condition).ForEach(DoSmth);
_FR>


А можно обосновать этот критерий — "слишком много"?
Применить действие Х по условию Y — вполне нормальная операция на мой взгляд.
Ты меняешь это на две операции:
Выбрать по условию Y
Применить действие Х для выбранного
Два раза бежим по списку — ну да бог с ним. Главное, какое проблема решена в результате? Ни одна из описываемых здесь "проблем" — не решается. И главное —

foreach (var x in list) if (Condition(x)) DoSmth(x);


по-прежнему самая короткая запись
Re[5]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 08:41
Оценка:
Здравствуйте, Ziaw, Вы писали:

ВВ>>foreach (var x in list)
ВВ>>  if (Condition(x))
ВВ>>    DoSmth(x);


Z>Если же в ForEach оставить только экшен — у него не останется преимуществ перед foreach.


Как так "не останется"? Например по guidelines принятым у нас в конторе guidelines вышеприведённый код расползается — угадай, на сколько строк?
1: foreach (var x in list)
2: {
3:   if (Condition(x))
4:   {
5:     DoSmth(x);
6:   }
7: }

и это предлагается вместо
list.Where(Condition).ForEach(DoSmth);

Help will always be given at Hogwarts to those who ask for it.
Re[6]: LINQ & Except
От: Ziaw Россия  
Дата: 11.06.09 08:48
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Как так "не останется"? Например по guidelines принятым у нас в конторе guidelines вышеприведённый код расползается — угадай, на сколько строк?


foreach (var x in list.Where(Condition))
{
  DoSmth(x);
}


Не очень убеждает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[6]: LINQ & Except
От: Ziaw Россия  
Дата: 11.06.09 08:48
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Два раза бежим по списку — ну да бог с ним.


Бежим один раз.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[5]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 08:56
Оценка:
Здравствуйте, IB, Вы писали:

_FR>>Мне показалось, что статья объясняет то, "почему Microsoft не предоставила для последовательностей метод расширения ForEach". Среди методов System.Linq.Enumerable.* ForEach действительно смотрелся бы странно.

IB>Эти же аргументы подходят и для того, чтобы не делать свой extension ForEach.

Вот первый:

Во-первых, это нарушило бы принципы функционального программирования, на которых основаны все остальные операторы на последовательностях.


foreach как-то вообще не очень совместим с "принципами функционального программирования", так что этот пункт обсуждать неинтересно. Или я не прав?

Во-вторых, такая возможность ничего не добавляет к выразительности языка. Она всего лишь позволяет вам переписать вот этот идеально понятный код… (в другом виде [прим. _FRED_])


Да, позволяет переписать "в другом". А что тут некошерного?

И вторую версию даже труднее понять и отладить, …


В том виде как это показывает Эрик:

foos.ForEach((Foo foo)=>{ какой-то оператор с foo; });

да, но есть же и более простые случаи:
foos.ForEach(DoSmth);


а еще она добавляет семантику замыкания, потенциально внося тонкие изменения в жизненные циклы объектов.


Это так же относится к злоупотреблению. Но со "злоупотреблением" нужно бороться другими методами, такими как рефакторинг, например.
Help will always be given at Hogwarts to those who ask for it.
Re[7]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 09:02
Оценка:
Здравствуйте, Ziaw, Вы писали:

_FR>>Как так "не останется"? Например по guidelines принятым у нас в конторе guidelines вышеприведённый код расползается — угадай, на сколько строк?

Z>foreach (var x in list.Where(Condition))
Z>{
Z>  DoSmth(x);
Z>}

Z>Не очень убеждает.

Расскажи пожалуйста о преимуществах Where в данном конкретном примере над if.
Help will always be given at Hogwarts to those who ask for it.
Re[6]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 09:06
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Это так же относится к злоупотреблению. Но со "злоупотреблением" нужно бороться другими методами, такими как рефакторинг, например.


Здесь я имел в виду то, что когда метод в ForEach становится сложным, и читать и отлаживать действительно непросто. Но сложно [плохо] написанный код тяжело поддаётся отладке во многих случаях и не потому что не надо "вредных" методов добавлять, а потому что не нужно сложно писать. А если писать "не сложно", то проблем с отладкой и читабельностью не будет.
Help will always be given at Hogwarts to those who ask for it.
Re[11]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 09:09
Оценка:
Здравствуйте, Ziaw, Вы писали:

ВВ>>Селект — это не аналог foreach.

Z>if -> Where()
Z>точно также как и
Z>foreach -> Select()

Правда что ли? Как же вы это сравниваете императивные конструкции и функциональными?

ВВ>>А причем тут функциональный стиль?

Z>при топике

Ну так перечитайте первое сообщение.

Z>Если предложите аналог заменяющий Where во всех сценариях использования можно будет обсуждать.


foreach

ВВ>>Единственный аргумент там — то, что ForEach — это не функционально. Аргумент весьма своеобразный на мой взгляд. Я вот никогда не видел приложение на шарпе написанное целиком функционально. Да и в Линк при желании можно запихать побочных эффектов по самое не могу — и все будет прекрасно работать.

Z>А я и не предлагаю писать все предложение функционально, я предлагаю не писать в функциональном стиле императивный код.

Таким образом мысль блога сводится к тому, что single statement lambda нельзя использовать в тех случаях, когда у нас есть побочные эффекты. Что предлагается взамен? Использовать простые делегаты, анонимные делегаты, заставлять себя вставлять фигурные скобки даже если лямбда состоит из одного выражения? Вывод какой? Или это так — просто потрепаться? Если я напишу:

list.ForEach(x => { DoSmth(x); });


То все, проблема снята? Или лучше вообще:

list.ForEach(delegate(Type x) => { DoSmth(x); });


Никакого функционального стиля, ага?
А теперь смотрим на саму функцию:

static void ForEach<T>(this IEnumerable<T> inst, Action<T> act) {...}


Возникает вопрос — а какой именно код написан функционально? Что вы предлагаете не писать в функциональном стиле? Использовать другой синтаксис для передачи колл-беков?

Используйте любой синтаксис, если считаете ввод подобных ограничений разумным. Только вот вопроса с ForEach и foreach это никак не касается.
Re[7]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 09:11
Оценка:
Здравствуйте, Ziaw, Вы писали:

ВВ>>Два раза бежим по списку — ну да бог с ним.

Z>Бежим один раз.

К сожалению, Линк не предоставляет нормальных средств для дебага — а так бы увидели, что это не так
Re[7]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 09:14
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Конечно: SRP, "Разделяй и влавствуй" и прочее и прочее — две функции, каждая из которых решает какую-то одну маленькую задачу лучше чем одна, решающая две две, что первые можно комбинировать. Вот пример — сколько у тебя сейчас перегрузок ForEach? Допустим, две:


Пример с ForEach не есть на нарушение SRP. Выполнить действие Х по условию У — это одна задача в императивном мире. Попробуй *все* функции на шарпе писать так, как ты предлагаешь, делая действия максимально атомарными, и огребешь кучу проблем — это с императивными-то функциями.

А ты сейчас принципы функционального программирования — атомарные ф-ции и все такое — пытаешься наложить на императивное. ForEach — не функционален. А разговор на самом деле идет о том, какой синтаксис использовать для его вызова

_FR>
_FR>void ForEach<T>(this IEnumerable<T>, Action<T>);
_FR>void ForEach<T>(this IEnumerable<T>, Predicate<T>, Action<T>);
_FR>

_FR>Но вот у меня есть ещё варианты ForEach, передающие в Action два параметра — элемент и его индекс. Тебе, что бы этого добиться и поддржать согласованость API придётся добавить две перегрузки:
_FR>
_FR>void ForEach<T>(this IEnumerable<T>, Action<T, int>);
_FR>void ForEach<T>(this IEnumerable<T>, Predicate<T>, Action<T, int>);
_FR>


А в твоем случае красивее будет?
Re[8]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 09:19
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А в твоем случае красивее будет?


В моём случае я имею только два метода:
void ForEach<T>(this IEnumerable<T>, Action<T>);
void ForEach<T>(this IEnumerable<T>, Action<T, int>);

Так как Where есть стандартный. И когда понадобится добавить что-то ещё в сигнатуру вызова, у меня и добавляется столько методов, сколько изменений требуется, а в твоём случае — приходится умножать на два.
Help will always be given at Hogwarts to those who ask for it.
Re[2]: LINQ & Except
От: Аноним  
Дата: 11.06.09 09:29
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Во-первых используем HashSet.


А зачем? Except внутри и сам использует Set (который hash):
[CompilerGenerated]
private sealed class <ExceptIterator>d__92<TSource> : IEnumerable<TSource>, IEnumerable, IEnumerator<TSource>, IEnumerator, IDisposable
{
    // Fields
    private int <>1__state;
    private TSource <>2__current;
    public IEqualityComparer<TSource> <>3__comparer;
    public IEnumerable<TSource> <>3__first;
    public IEnumerable<TSource> <>3__second;
    public IEnumerator<TSource> <>7__wrap95;
    private int <>l__initialThreadId;
    public TSource <element>5__94;
    public Set<TSource> <set>5__93;
    public IEqualityComparer<TSource> comparer;
...
...
}
Re[9]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 09:33
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Так как Where есть стандартный. И когда понадобится добавить что-то ещё в сигнатуру вызова, у меня и добавляется столько методов, сколько изменений требуется, а в твоём случае — приходится умножать на два.


Хорошо, а с чем боремся-то? Сократить кол-во функций любой ценой? Так ты же говорил, что функции должны быть атомарными, что их будет много и так далее.
Потом на самом деле в моем случае придется делать перегрузки одной функции, а в твоем, если уж честно рассматривать разнообразные сценарии, двух. И преимущество опять-таки непонятно.

Тут основная претензия ко мне — это что я предлагаю использовать функциональный стиль для императивного кода. С чем я и не спорю. Ты же на самом деле идешь еще дальше и предлагаешь принципы написания функционального кода использовать для императивного

А проблема-то на самом деле уходит корнями в тот факт, что нам предложили красивый и модный синтаксис для выборок, а вот для изменений, которые как бы не менее редкие, не предложили. Что особенно явно и чувствуется на примере какого-нибудь linq2sql. Недаром товарищи вроде ИТ да Влада бьются как бы эти самые лямбды к инсертам да апдейтам прикрутить, используя весьма функциональный синтаксис для весьма, надо сказать, императивных действий. И да, с одной стороны, неправильно это, о чем я сам, кстати, и говорил А с другой стороны — что делать? То, что ты предлагаешь — это тоже не вариант. Это вообще франкейнштейн какой-то.
Re[6]: LINQ & Except
От: Ziggi111 Россия  
Дата: 11.06.09 09:46
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, Ziggi111, Вы писали:


Z>>ИМХО

Z>>
Z>>list.ForEach(x => DoSmth(x), x => Condition(x));
Z>>

Z>>читается не лучше, но, как и сказано в указанном блоге, недебагебелбно

ВВ>Это в блоге "недебагебелбно" У меня-то все дебагебельно — код в соседней сборке лежит

ага... и на каждый ForEach туда падает... чудо а не дебаг...
я не против такой реализации, сам так иногда делаю, но в какой-то момент понял, что Липперт прав
Re[8]: LINQ & Except
От: Ziaw Россия  
Дата: 11.06.09 09:47
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR> Расскажи пожалуйста о преимуществах Where в данном конкретном примере над if.


Наглядность, мы сразу видим, что идем по отфильтрованному списку.

В случае с if нам нужно:
1. Увидеть паттерн foreach/if
2. Понять, что условие там зависит только от элемента

Два действия вместо одного.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[9]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 10:02
Оценка:
Здравствуйте, Ziaw, Вы писали:

_FR>> Расскажи пожалуйста о преимуществах Where в данном конкретном примере над if.

Z>Наглядность, мы сразу видим, что идем по отфильтрованному списку.

Здесь кто-то не видит, что мы "идем по отфильтрованному списку"?
list.Where(Condition).ForEach(DoSmth);


Z>В случае с if нам нужно:

Z>1. Увидеть паттерн foreach/if
Z>2. Понять, что условие там зависит только от элемента
Z>Два действия вместо одного.

Как контр-аргумент могу привести непригодность к рефакторингу варианта c Where — если понадобится как-то особым образом обработать элементы, не удовлетворяющие условию, придётся писать больше кода, нежели в случае, если бы if стоял бы внутри for.

С другой стороны, все эти "Наглядность, Увидеть, Понять" как раз попадают под слова

…такая возможность ничего не добавляет к выразительности языка…

И … даже труднее… отладить, а еще она добавляет семантику замыкания, потенциально внося тонкие изменения в жизненные циклы объектов

…Когда мы предоставляем два почти одинаковых способа сделать в точности одну вещь, мы вносим сумятицу в индустрию, мы затрудняем людям чтение кода друг друга, и так далее

Help will always be given at Hogwarts to those who ask for it.
Re[10]: LINQ & Except
От: Ziaw Россия  
Дата: 11.06.09 10:17
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Здесь кто-то не видит, что мы "идем по отфильтрованному списку"?

_FR>
list.Where(Condition).ForEach(DoSmth);


Здесь вообще нет уверенности что мы идем по нему. =) linq ленив.

_FR>Как контр-аргумент могу привести непригодность к рефакторингу варианта c Where — если понадобится как-то особым образом обработать элементы, не удовлетворяющие условию, придётся писать больше кода, нежели в случае, если бы if стоял бы внутри for.


Да нет никакой обработки во Where(), есть только выборка. Если нам нужно обработать все — нам не нужно Where вообще. Два разных подхода — выбрать то что нужно (функция, результат на ладони, можно вызвать сколько угодно раз, может быть ленива) и обработать (действие, должно быть выполнено один и только один раз, результат за кадром).

Функциональный стиль отлично работает и естественно смотрится в выборке и плохо в обработке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[11]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 10:22
Оценка:
Здравствуйте, Ziaw, Вы писали:

_FR>>Здесь кто-то не видит, что мы "идем по отфильтрованному списку"?

_FR>>
list.Where(Condition).ForEach(DoSmth);


Z>Здесь вообще нет уверенности что мы идем по нему. =) linq ленив.


При чём здесь linq? метод Where осуществляет выборку, ForEach — действие.

_FR>>Как контр-аргумент могу привести непригодность к рефакторингу варианта c Where — если понадобится как-то особым образом обработать элементы, не удовлетворяющие условию, придётся писать больше кода, нежели в случае, если бы if стоял бы внутри for.


Z>Да нет никакой обработки во Where(), есть только выборка.


Я нигде и не говорил, про обработку "во Where()". Прочитай пожалуйста внимательнее.

Z>Если нам нужно обработать все — нам не нужно Where вообще.


Я говорил о том, что если нам понадобится как-то обработать то, что не прошло через Where() то переписывать придётся больше, чем в случае с if.

Z>Два разных подхода — выбрать то что нужно (функция, результат на ладони, можно вызвать сколько угодно раз, может быть ленива) и обработать (действие, должно быть выполнено один и только один раз, результат за кадром).

Z>Функциональный стиль отлично работает и естественно смотрится в выборке и плохо в обработке.

Какое это имеет отношение к тому, что я написал?
Help will always be given at Hogwarts to those who ask for it.
Re[11]: LINQ & Except
От: Lloyd Россия  
Дата: 11.06.09 10:22
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>if -> Where()

Z>точно также как и
Z>foreach -> Select()


foreach — это while, while — это if + goto => Select == Where + goto
Re[11]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 10:48
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>То, что я предлагаю называется функциональной декомпозицией и к "функциональному стилю" отношения не имеет никакого, поскольку применима в любом стиле программирования (при наличии подпрограмм).


Да ты что? Давай тогда быть последовательными, товарищ. Как ты производишь замену внутри строки, чтобы была "функциональная декомпозиция" и не было "нарушения SRP"?

Я делаю String.Replace.
Re[7]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 10:51
Оценка:
Здравствуйте, Ziggi111, Вы писали:

ВВ>>Это в блоге "недебагебелбно" У меня-то все дебагебельно — код в соседней сборке лежит

Z>ага... и на каждый ForEach туда падает...

Куда падает? Я дебажить буду саму реализацию ф-ции ForEach.

Z>чудо а не дебаг...


А Линк вы как дебажите? Ровно та же проблема.

Z>я не против такой реализации, сам так иногда делаю, но в какой-то момент понял, что Липперт прав


Ну правильно, они прикрутили к бабе яйца, а теперь же надо какие-то рекомендации для народа придумывать. Типа в этой позе можно, а в этой уже... эээ... "неженственно". А что они раньше-то думали?
Re[9]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 13:22
Оценка:
Здравствуйте, IB, Вы писали:

ВВ>>Спасибо, я читаю по-английски.

IB>Видимо стоило, все-таки по русски. Ну ладно, я разжую. Аргументов там два, и оба отличаются от того, который ты нашел:

IB>1. Речь не о том, что функционально это или нет, а о том, что вся работа с последовательностями дизайнилась в функциональном стиле, а такой метод этот стиль нарушает. Иными словами, такой вариант противоречит дизайну языка, не важно какой сам по себе дизайн, функциональный или не очень. И там подробно разжевано почему.


При чём здесь "дизайн языка", когда речь о библиотечном методе? Слова были о дизайне библиотеки, о том, что данные метод плохо бы смотрелся среди других методов.

Я вижу слова "Я философски против предоставления такого метода по двум причинам." и не вижу "наличия". Да и в любом случае — мнение, высказаное в блоге является личным мнением Эрика или мнением команды, разрабатывавшей System.Core. Я не вижу ответа в тексте блога на вопрос "почему плохо в своём коде иметь такой метод". Всё, что можно понять — это рекомендации основанные на том, что "добавляет семантику замыкания" (1), "труднее понять" (2) и "труднее … отладить" (3).

По пунктам:

1. никто не заставляет пользоваться замыканиями, так что данное обоснование кажется надуманным. Ведь никто же не запрещает использовать замыкания и side effects в методах, передаваемых в Select или Where.

2. Это вопрос самый спорный. Например варианты здесь
Автор: _FRED_
Дата: 11.06.09
мне кажутся не трудными.

3. Мне гораздо несимпатичнее отладка такого кода:
Some1();

for(var x in yy) {
  // … сотня-другая итераций
}//fir

Some2();

когда меня не интересуют внутренности работы цикла (требуется от Some1 перейти к Some2). Отладчик не умеет "перепрагивать" через цикл и приходится ставить специальный breakpoint к Some2(); и перепрыгивать цикл самому.

IB>И при всем при этом, совершенно непонятно какую выгоду такое расширение может принести — полторы строчки кода, это не серьезно, тем более, что почти такого же эффекта можно добиться стандартными средствами.


Использование одной строчки там, где в другом случае нужно много больше. (здесь
Автор: _FRED_
Дата: 11.06.09
)

IB>Резюме: При кажущейся простоте, такой метод не предоставляя реальных преимуществ


Для стандартной библиотеки — да. Точно так же можно предать анафеме хелперы типа такого. Без ниже прекрасно можно обойтись. Но с ними лучше.

IB>…затрудняет понимание кода и способен привести к малопредсказуемым побочным эффектам.


Мне кажется, что этих эффектом можно добиться и без ForEach. Одновременно с этим, с ForEach можно этих же эффектов избежать. И причина возникновения эффектов не в ForEach, а в содержимом черепной коробки
Help will always be given at Hogwarts to those who ask for it.
Re[9]: LINQ & Except
От: Воронков Василий Россия  
Дата: 11.06.09 13:30
Оценка:
Здравствуйте, IB, Вы писали:

IB>Видимо стоило, все-таки по русски.


Знаешь, "по-русски" я бы тебе давно уже объяснил, что я думаю о подобных гайдлайнах — да боюсь забанят.

IB>1. Речь не о том, что функционально это или нет, а о том, что вся работа с последовательностями дизайнилась в функциональном стиле, а такой метод этот стиль нарушает.


*Вся* работа с последовательностями ли, с базой данных и пр. уж никак не может вестись в одном стиле, о чем уже так долго говорят большевики и с чем, видимо, придется смириться.
А в данном случае непонятно — откуда возникает требование этого функционального стиля? Если передо мной стоят задачи модификации или, не дай бог, появляются методы имеющие сохраняемое состояние — то причем здесь вообще функциональный стиль? И почему это должно быть функционально, если в действительности это не функционально ни на йоту?
Это мы только ForEach<> касаемся, а можно еще и рассмотреть всякие Aggregate<> — там ведь вообще ужас с этой точки зрения.

Да, и я уже приводил этот пример.
String.Replace — очень схожая задача с обсуждаемой здесь. И совершенно нефункционально. И при этом самая что ни на есть последовательность. В каком стиле предлагаете проводить замену?

IB>Иными словами, такой вариант противоречит дизайну языка, не важно какой сам по себе дизайн, функциональный или не очень. И там подробно разжевано почему.


Дизайну Шарпа противоречит императивный стиль?
Функциональному дизайну Линка, который здесь вообще не причем, противоречит императивный стиль?
Вам дали библиотеку со "спецэффектами" и теперь уже стиль у языка другой?

IB>2. Выразительности такой код не добавит, а наоборот, запутает и, плюс к этому, "добавляет семантику замыкания, потенциально внося тонкие изменения в жизненные циклы объектов." То есть, реально, такой метод ухудшает имеющийся оператор foreach, добавляя малопредсказуемые побочные эффекты.


То же самое можно сказать и про Where по сравнению с foreach.

IB>И при всем при этом, совершенно непонятно какую выгоду такое расширение может принести — полторы строчки кода, это не серьезно, тем более, что почти такого же эффекта можно добиться стандартными средствами.

IB>Резюме: При кажущейся простоте, такой метод не предоставляя реальных преимуществ затрудняет понимание кода и способен привести к малопредсказуемым побочным эффектам.

Именно так говорят люди, когда не хотят пересаживаться с фор-ичей на Линк
Re[11]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 13:41
Оценка:
Здравствуйте, koandrew, Вы писали:

_FR>>когда меня не интересуют внутренности работы цикла (требуется от Some1 перейти к Some2). Отладчик не умеет "перепрагивать" через цикл и приходится ставить специальный breakpoint к Some2(); и перепрыгивать цикл самому.


K>Ctrl+F10 спасут отца русской демократии И без всяких бряков


Что это за команда и как она поможет?
Help will always be given at Hogwarts to those who ask for it.
Re[14]: LINQ & Except
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 11.06.09 14:57
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Во ё-моё, а мне казалось что эта команда заставляет отладчик перепрыгнуть к курсору


Я же сказал, что спасёт
[КУ] оккупировала армия.
Re[11]: LINQ & Except
От: _FRED_ Черногория
Дата: 11.06.09 15:14
Оценка:
Здравствуйте, IB, Вы писали:

_FR>>При чём здесь "дизайн языка", когда речь о библиотечном методе?

IB>А библиотечный метод как-то в отрыве от языка существует?

Это не значит, что задачи дизайна языка можно сравнивать с задачами дизайна библиотеки. Здесь речь о дизайне библиотеки.

_FR>>Я не вижу ответа в тексте блога на вопрос "почему плохо в своём коде иметь такой метод".

IB>Аргументов в этой заметке достаточно и для моего кода.

Всё, что из этого видно — то, что ты или веришь каким-то шестым чувством автору блога, или что вы с автором чего-то такое понимаете, что вам не удаётся онести до простых смертных (посмотри сколько там коментов написали такие же непонявшие). Так вот ни одна из этих причин не является обоснованной для "такого вот" давления на тех, "кто в танке". До тех пор, пока аргументы не будут ясны и понятны всем. Хорошо?

_FR>>1. никто не заставляет пользоваться замыканиями, так что данное обоснование кажется надуманным.

IB>Никто не заставляет вообще пользоваться этим методом. Зачем мне метод с побочными эффектами, если можно обойтись без них, стандартными средствами?

Я уже сказал — просто продлить жизнь клавиатуре.

_FR>>2. Это вопрос самый спорный.

IB>Наоборот, самый бесспорный =) plain foreach — чище, очевиднее и понятнее любого метода с Action<T> в качестве аргумента, я не понимаю, какие тут вообще могут быть сомнения..

Отлично. Тогда и показанный здесь
Автор: _FRED_
Дата: 11.06.09
хелпер, следуя твоей логике, не нужен? Ибо использование using в таком сценарии так же можно воспринять как неочевидность. Давайте захломлять код try\finnaly — добавляют ли они по-твоему "чистоты"? И если "нет", то почему foreach добавляет?

_FR>>Использование одной строчки там, где в другом случае нужно много больше.

IB>Не много, а ровно на одну — я уже писал, что этот аргумент вообще несерьезный.

Перечитал твои посты в этой ветке — не нашёл. Ткни пожалуйста.

_FR>>Для стандартной библиотеки — да.

IB>Для нестандартной тоже. Другие аргументы, кроме числа строк кода есть?

Нет.
Help will always be given at Hogwarts to those who ask for it.
Re[12]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 12.06.09 13:48
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Здесь речь о дизайне библиотеки.

Ну вот и не надо писать такие библиотечные методы.

_FR>Всё, что из этого видно — то, что ты или веришь каким-то шестым чувством автору блога, или что вы с автором чего-то такое понимаете, что вам не удаётся онести до простых смертных

Либо эти простые смертные настрлько любят свой ForEach, до которого додумались, что никакие рациональные аргументы их не интересуют.

_FR> Так вот ни одна из этих причин не является обоснованной для "такого вот" давления на тех, "кто в танке". До тех пор, пока аргументы не будут ясны и понятны всем. Хорошо?

На тех кто в танке — никто не давит. Я высказал свое мнение и свое отношение к этому вопросу, хорошо? А лечить тех кто в танке у меня нет ни малейшего желания.

_FR>Я уже сказал — просто продлить жизнь клавиатуре.

На аргумент не тянет, так как, например, по нашим стандартам, даже по числу нажатий на Enter оба варианта не отличаются.

_FR>Отлично. Тогда и показанный здесь
Автор: _FRED_
Дата: 11.06.09
хелпер, следуя твоей логике, не нужен?

Какой хелпер?

_FR>Перечитал твои посты в этой ветке — не нашёл. Ткни пожалуйста.

В очередном ответе Васе Воронкову.

IB>>Другие аргументы, кроме числа строк кода есть?

_FR>Нет.
Ну, вот собственно и все.
Мы уже победили, просто это еще не так заметно...
Re[14]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 12.06.09 14:27
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вас видимо сильно мучают на работе, раз возникает желание с таким компентеным видом вдалбливать всем "пургу". Что ж, сочувствую. Попробуйте чаще использовать мозг — может, и жизнь тогда наладится.

Эх, Василий... Если бы ты сам последовал своему совету, и применил свой мозг по назначению, хотя бы попытавшись понять, что тебе говорят, вместо того, чтобы неуклюже стараться уязвить оппонента во что бы то ни стало — глядишь бы и вышел толк... Но увы.
Мы уже победили, просто это еще не так заметно...
Re[15]: LINQ & Except
От: Воронков Василий Россия  
Дата: 12.06.09 14:46
Оценка:
Здравствуйте, IB, Вы писали:

ВВ>>Вас видимо сильно мучают на работе, раз возникает желание с таким компентеным видом вдалбливать всем "пургу". Что ж, сочувствую. Попробуйте чаще использовать мозг — может, и жизнь тогда наладится.

IB>Эх, Василий... Если бы ты сам последовал своему совету, и применил свой мозг по назначению, хотя бы попытавшись понять, что тебе говорят, вместо того, чтобы неуклюже стараться уязвить оппонента во что бы то ни стало — глядишь бы и вышел толк... Но увы.

Правда что ли, товарищ? Хамить почему-то всегда вы начинаете, видимо, считая, что ваше мнение уж настолько бесспорно, что любое потенциальное несогласие с ним — признак недалекого ума. Может, проще оставить свое мнение при себе, тогда и возражать никто не будет?
Если немножко подумать, что можно, наверное, заметить, что никакой по сути разницы между foreach и ForEach нет, кроме той самой "тонкой семантики замыкания", которая наблюдается еще в 22-х экстеншин методах вроде All, Count, Aggregate и пр., где за не фиг делать можно наплодить побочных эффектов и которые все-таки включили в пространство имен Linq. И то, что у вас, извините, выражение собственного мнения, что ForEach ни в каком виде не нужен, превращается в итоге в беседу в стиле "ты дурак", "нет, сам дурак", какой-то немножко характерный показатель, не находите?
Re[18]: LINQ & Except
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.06.09 13:22
Оценка:
Здравствуйте, Аноним, Вы писали:

А>чем интересно можно себя настолько зомбировать ("эрик! преклоняюсь перед тобой о светочЪ и истина в первой инстанции" (С) IB), чтобы нести нереальную пургу выдуманную исключительно в оправдание лени/тупости/индусости разработчиков BCL в отношении ForEach?

Да, видимо уже модой стало считать себя умнее кучи разработчиков в MS.

А>Label:

А>Читай что ли по слогам (ну конечно, в яслях читать еще не умеют): ForEach метод предназначен для обработки последовательности и не имеет Н И К А К О ГО отношения к linq. Ты способен это понять? Если нет, то goto (его осилишь?) Label;
Если ты так считаешь, то пиши свой ForEach, не запрещается. Другим доказывать ничего не надо.

А>Более того, ForEach может быть своим у последовательностей разных типов. Давай, вперед, используй циклы for — они же нии%ически доступны для понимания. Задайся вопросом (ну или почитай что-нибудь кроме липпппертов на досуге), почему в С++ STL есть for_each и его крайне рекомендуют использовать а не обходить последовательности вручную!

А причем тут for и C++? В C# есть стандартная конструкция foreach.

ЗЫ. В F# есть Seq.iter для прохода по коллекции, а for .. in может работать и как foreach, и как map. Никто пока не умер.
Re[19]: LINQ & Except
От: Аноним  
Дата: 13.06.09 15:18
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Да, видимо уже модой стало считать себя умнее кучи разработчиков в MS.

не пиши мне. читай липберта.

G>Если ты так считаешь, то пиши свой ForEach, не запрещается. Другим доказывать ничего не надо.

тебе лично я ничего не писал/не доказывал/etc.
btw, доказывает с пеной у рта тут только один человек — IB. нереально навязывает "правоту" мыслей либберта, несогласных пытается предать "анафеме" как иноверцев. вот к чему был мой пост.

G>А причем тут for и C++? В C# есть стандартная конструкция foreach.

правда? я не знал, спасибо что подсказал. юзай стандартный цикл for. он куда более стандартен, понятен, доступен
Re[20]: LINQ & Except
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.06.09 16:02
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:


G>>Да, видимо уже модой стало считать себя умнее кучи разработчиков в MS.

А>не пиши мне. читай липберта.
Это тебе стоит прочитать этот пост. Особенно последнюю строчку

Если вы не согласны с этими философскими возражениями и находите в этом приёме практическую ценность, определенно не сдерживайте себя и напишите эту тривиальную строчку сами.



G>>А причем тут for и C++? В C# есть стандартная конструкция foreach.

А>правда? я не знал, спасибо что подсказал. юзай стандартный цикл for. он куда более стандартен, понятен, доступен
Это уже бред воспаленного воображения.
Re[8]: LINQ & Except
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.06.09 18:03
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>К сожалению, Линк не предоставляет нормальных средств для дебага — а так бы увидели, что это не так


Линк может и не предоставляет, но определить это совсем несложно.
using System;
using System.Collections.Generic;
using System.Linq;

namespace WhereForeach
{
    static class Program
    {
        static IEnumerable<int> TestEnum()
        {
            yield return 1;
            Console.WriteLine(1);
            yield return 2;
            Console.WriteLine(2);
            yield return 3;
            Console.WriteLine(3);
        }

        public static void ForEach<T>(this IEnumerable<T> source, Action<T> action)
        {
            foreach (var item in source)
                action(item);
        }

        static void Main()
        {
            TestEnum().Where(i => i == 2).ForEach(i => Console.WriteLine("Action " + i));
        }
    }
}

Вывод
1
Action 2
2
3

Так сколько раз?
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[9]: LINQ & Except
От: Воронков Василий Россия  
Дата: 15.06.09 18:10
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Так сколько раз?


Два
Товарищ, вы смешиваете напитки

TestEnum() выполняется, естественно, один раз. Он формирует набор элементов, по которому осуществляет проход наш ForEach — и это второй раз. Именно об этом я и говорил. Т.е. сначала проход по коллекции с целью выборки, затем проход по выборке с целью выполнения действия.

Что кстати в твоем примере и видно:

AVK>Action 2
AVK>2


А вот в случае с методом ForEach<T>(this IEnumerable<T> source, Action<T> action, Func<bool> condition) проход по коллекции будет вообще один.
Re[11]: LINQ & Except
От: Воронков Василий Россия  
Дата: 15.06.09 18:50
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Вывод на консоль тот же. Удивительно, правда?


Да, интересно, Where не выполняет IEnumerable, а создает обвертку над ним обвертку и выполняет, используя переданное условие. С другой стороны, вполне логичное поведение, странно, что я ожидал что-то другое. Что ж, будем знать
Re[12]: LINQ & Except
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.06.09 21:13
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Да, интересно, Where не выполняет IEnumerable, а создает обвертку над ним обвертку и выполняет, используя переданное условие.


Не не не. Ты мне объясни, каким образом получаются два прохода по итератору, если итератор вызывается ровно один раз? Единственный способ — переписать итератор в массив. Ты уверен в том, что Enumerable.Where это делает?

ВВ> С другой стороны, вполне логичное поведение, странно, что я ожидал что-то другое.


Ну, ты много очень странных мыслей сегодня высказал
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[13]: LINQ & Except
От: Воронков Василий Россия  
Дата: 15.06.09 21:22
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не не не. Ты мне объясни, каким образом получаются два прохода по итератору, если итератор вызывается ровно один раз? Единственный способ — переписать итератор в массив. Ты уверен в том, что Enumerable.Where это делает?


Да посмотрел я уже Мне казалось, что он и правда куда-то переписывает. Что странно, так как, насколько я вспомнил, я и раньше это смотрел тоже. Видимо, меня зазомбировали.

ВВ>> С другой стороны, вполне логичное поведение, странно, что я ожидал что-то другое.

AVK>Ну, ты много очень странных мыслей сегодня высказал

Сегодня странных мыслей вроде бы больше не было... Может, ты про вчерашнее?
Re[14]: LINQ & Except
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.06.09 21:28
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Да посмотрел я уже Мне казалось, что он и правда куда-то переписывает. Что странно, так как, насколько я вспомнил, я и раньше это смотрел тоже.


Ну точно, Михайлик №2
... << RSDN@Home 1.2.0 alpha 4 rev. 1227 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[11]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.06.09 08:55
Оценка:
Здравствуйте, IB, Вы писали:
_FR>>2. Это вопрос самый спорный.
IB>Наоборот, самый бесспорный =) plain foreach — чище, очевиднее и понятнее любого метода с Action<T> в качестве аргумента, я не понимаю, какие тут вообще могут быть сомнения..
Единственное место, где екстеншн-метод с Action<T> смотрится более прикольно — это когда вместо замыкания туда передаётся готовый делегат.
Зацени:
public static void Main(string args[])
{
  args.ForEach(Console.WriteLine);
}

Это по сравнению с
public static void Main(string args[])
{
  foreach(var a in args)
        Console.WriteLine(a);
}

Такой способ применения позволяет обойтись без введения временной переменной, весь смысл которой — дотащить текущий элемент до вызова.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.06.09 09:12
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>*Вся* работа с последовательностями ли, с базой данных и пр. уж никак не может вестись в одном стиле, о чем уже так долго говорят большевики и с чем, видимо, придется смириться.

Странно. Это какие большевики? Наши большевики как раз говорят о том, что вся встроенная во фреймворк работа с последовательностями ведется в одном стиле.

ВВ>А в данном случае непонятно — откуда возникает требование этого функционального стиля? Если передо мной стоят задачи модификации или, не дай бог, появляются методы имеющие сохраняемое состояние — то причем здесь вообще функциональный стиль? И почему это должно быть функционально, если в действительности это не функционально ни на йоту?

ВВ>Это мы только ForEach<> касаемся, а можно еще и рассмотреть всякие Aggregate<> — там ведь вообще ужас с этой точки зрения.
Правда что ли? У Aggrgate<> нет никакого изменяемого состояния.

ВВ>String.Replace — очень схожая задача с обсуждаемой здесь. И совершенно нефункционально. И при этом самая что ни на есть последовательность. В каком стиле предлагаете проводить замену?

Судя по этому примеру, ты не вполне понимаешь, что такое ФП. string.Replace — 100% функциональна. У неё нет побочных эффектов!

ВВ>Функциональному дизайну Линка, который здесь вообще не причем, противоречит императивный стиль?

Функциональному дизайну Linq2Objects, реализованному в хелперах для IEnumerable<T>, противоречит императивный стиль.

ВВ>Вам дали библиотеку со "спецэффектами" и теперь уже стиль у языка другой?

Нам дали библиотеку без спецэффектов.

ВВ>То же самое можно сказать и про Where по сравнению с foreach.

Увы, нельзя. Семантика where не сводится к foreach(var item in source ) if condition(item) action(item).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: LINQ & Except
От: Воронков Василий Россия  
Дата: 23.06.09 09:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

ВВ>>*Вся* работа с последовательностями ли, с базой данных и пр. уж никак не может вестись в одном стиле, о чем уже так долго говорят большевики и с чем, видимо, придется смириться.

S>Странно. Это какие большевики? Наши большевики как раз говорят о том, что вся встроенная во фреймворк работа с последовательностями ведется в одном стиле.

Те, которые хотят при работе с linq2sql изменения данных также делать средствами linq. Имена, явки давать?

ВВ>>А в данном случае непонятно — откуда возникает требование этого функционального стиля? Если передо мной стоят задачи модификации или, не дай бог, появляются методы имеющие сохраняемое состояние — то причем здесь вообще функциональный стиль? И почему это должно быть функционально, если в действительности это не функционально ни на йоту?

ВВ>>Это мы только ForEach<> касаемся, а можно еще и рассмотреть всякие Aggregate<> — там ведь вообще ужас с этой точки зрения.
S>Правда что ли? У Aggrgate<> нет никакого изменяемого состояния.

Хочешь я напишу реализацию, у которой будет? У ForEach<> точно так же нет состояния by design, точно так же можно написать кучу прекрасного кода, в котором никакого состояния и не будет. А можно написать кучу кода с Aggregate<>, у которого будет состояние.
А все потому что, как тут говорят некоторые товарищи, Aggregate<> "вносит тонкую семантику замыкания". Я вот не вижу здесь принципиальной разницы между Aggregate<> и ForEach<>.

ВВ>>String.Replace — очень схожая задача с обсуждаемой здесь. И совершенно нефункционально. И при этом самая что ни на есть последовательность. В каком стиле предлагаете проводить замену?

S>Судя по этому примеру, ты не вполне понимаешь, что такое ФП. string.Replace — 100% функциональна. У неё нет побочных эффектов!

Ты судя по всему не вполне прочитал ветку. У меня у ForEach<> тоже побочных эффектов нет. Это Фред вот заговорил о том, что ф-ция ForEach<> в предлагаемом варианте плоха, т.к. она совмещает два действия — применить некое действие к элементам массива, выполнить условие — и советовал использовать "функциональную декомпозицию". Я ему посоветовал использовать функциональную декомпозицию для String.Replace.

ВВ>>Функциональному дизайну Линка, который здесь вообще не причем, противоречит императивный стиль?

S>Функциональному дизайну Linq2Objects, реализованному в хелперах для IEnumerable<T>, противоречит императивный стиль.

А причем здесь эти хелперы? Речь не о том, стоило ли включать ForEach<> в пространство имен Линк. Я этого вообще никогда не предлагал. Речь о том, является ли ф-ция ForEach<> абсолютным и беспрекословным злом.
И как я уже говорил "угроза подобных эффектов" там не выше чем у того же Aggregate<>.

ВВ>>То же самое можно сказать и про Where по сравнению с foreach.

S>Увы, нельзя. Семантика where не сводится к foreach(var item in source ) if condition(item) action(item).

Разве Where не "добавляет семантику замыкания, потенциально внося тонкие изменения в жизненные циклы объектов"? Тебе привести пример Where с подобными эффектами?
Re[13]: LINQ & Except
От: Воронков Василий Россия  
Дата: 23.06.09 10:30
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Единственный смысл ForEach — получение побочных эффектов. Это понятно?


Это ты сам сейчас придумал. А для меня ForEach отличается от Aggregate только отсутствием аккумулятора и возвращаемого значения, что для настоящих джедаев не помеха при написании пьюре функции.

ВВ>>А все потому что, как тут говорят некоторые товарищи, Aggregate<> "вносит тонкую семантику замыкания". Я вот не вижу здесь принципиальной разницы между Aggregate<> и ForEach<>.

S>Принципиальная разница — в том, что Aggregate остаётся ленивым. Семантика замыкания в его случае полностью оправдана — мы всё еще описываем способ получения одних данных из других. В случае ForEach мы имеем энергичную семантику "немедленно примени мне здесь побочные эффекты, которые я описал в Action<T>".

Так сделаем ForEach ленивым

ВВ>>Ты судя по всему не вполне прочитал ветку. У меня у ForEach<> тоже побочных эффектов нет.

S>Да ладно!
S>Если у него нет побочных эффектов, то его можно просто не вызывать.

Да ладно. У тебя просто фантазия неразвита
Даю хинт — никто не запрещает в чистых функциях генерировать исключения.

ВВ>>А причем здесь эти хелперы? Речь не о том, стоило ли включать ForEach<> в пространство имен Линк. Я этого вообще никогда не предлагал. Речь о том, является ли ф-ция ForEach<> абсолютным и беспрекословным злом.

S>Конечно же нет. Например, функция List<T>.ForEach беспрекословным злом не является. А вот хелпер для IEnumerable — является, о чём недвусмысленно написал Эрик.

Эрик писал что:
— бла-бла-бла, поэтому этого нет в пространстве имен Лин
— бла-бла-бла, я считаю, что эта функция с философской точки зрения полный отстой, но если вам так хочется, реализуйте ее сами.

Как-то мне сложно из этого сделать вывод, что List<T>.ForEach это нормально, а IEnumerable.ForEach — зло.

А вообще причем тут побочные эффекты и проч.? Не нравится использовать замыкания для побочных эффектов? А каллбеки вообще можно использовать? К чему суть спора сводится-то?
Re[13]: LINQ & Except
От: _FRED_ Черногория
Дата: 23.06.09 10:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Например, функция List<T>.ForEach беспрекословным злом не является. А вот хелпер для IEnumerable — является, о чём недвусмысленно написал Эрик.


Вот ещё один толкователь Мужики, вы понятным языком можете рассказать, что и где вы там видите или сами понимаете?

Ключевой смысл, я полагаю, имеет предложение

Мне как-то не нравится идея сделать единственный оператор для последовательностей, который полезен только для спецэффектов.

Но что в этом плохого? Ведь есть же какие-то причины? Или это всё на уровне подсознания?
Почему-то из критиков тут никто ещё не продвинулся дальше этого "не нравится"

Методов, имеющих своей целью создание побочных эффектов множество. Они все не правы? Или именно ForEach на их фоне чем-то выделяется? Ну хоть забань меня модератор, не вижу чем же именно
Help will always be given at Hogwarts to those who ask for it.
Re[13]: LINQ & Except
От: _FRED_ Черногория
Дата: 23.06.09 10:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Например, функция List<T>.ForEach беспрекословным злом не является. А вот хелпер для IEnumerable — является, о чём недвусмысленно написал Эрик.


Отличный пример! Разве целью приведённого решения не является создание побочных эффектов? А насколько такое решение "функционально"?
Help will always be given at Hogwarts to those who ask for it.
Re[14]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.06.09 10:57
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Это ты сам сейчас придумал.

Нет. Читать здесь.
Покажи мне применение ForEach, в котором нет побочных эффектов.
ВВ>А для меня ForEach отличается от Aggregate только отсутствием аккумулятора и возвращаемого значения, что для настоящих джедаев не помеха при написании пьюре функции.
pure function без возвращаемого значения эквивалентна {}. Это знают даже падаваны, а уж настоящим джедаям это положено знать — иначе лайтсабер никто не даст.

ВВ>Так сделаем ForEach ленивым

Можно в студию пример ленивого форича?

ВВ>Даю хинт — никто не запрещает в чистых функциях генерировать исключения.

Это и будет побочным эффектом.

ВВ>А вообще причем тут побочные эффекты и проч.? Не нравится использовать замыкания для побочных эффектов? А каллбеки вообще можно использовать? К чему суть спора сводится-то?

К тому, что некоторые люди не могут понять простую и короткую статью даже после многократного прочтения. Больше никакой сути в споре нету.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.06.09 11:13
Оценка:
Здравствуйте, _FRED_, Вы писали:
_FR>Отличный пример! Разве целью приведённого решения не является создание побочных эффектов? А насколько такое решение "функционально"?
Абсолютно нефункционально. Это специальная штука, которая придаёт побочные эффекты тому, у чего их не было — для того, чтобы ты мог визуально наблюдать "путь исполнения" декларативного запроса.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: LINQ & Except
От: _FRED_ Черногория
Дата: 23.06.09 11:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

_FR>>Вот ещё один толкователь Мужики, вы понятным языком можете рассказать, что и где вы там видите или сами понимаете?


_FR>>Ключевой смысл, я полагаю, имеет предложение

_FR>>

Мне как-то не нравится идея сделать единственный оператор для последовательностей, который полезен только для спецэффектов.

_FR>>Но что в этом плохого?
S>В том, что он будет единственным. Это нарушает вселенскую симметрию linq2objects.
S>В классе List<T> дохрена методов, рассчитанных на побочные эффекты, поэтому там (как и в Array) ForEach уместен. Для IEnumerable он будет слишком неожиданным.

_FR>>Методов, имеющих своей целью создание побочных эффектов множество.

S>В Linq2Objects таких методов нет.

Спасибо, то что надо.

Какое отношение этот вот метод
  static class Sequence
  {
    public static void ForEach<TSource>(this IEnumerable<TSource> source, Action<TSource> action) {
      foreach(var item in source) {
        action(item);
      }//for
    }
  }

имеет к a) Linq2Objects б) IEnumerable ц) дизайну языка C#
Help will always be given at Hogwarts to those who ask for it.
Re[11]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 23.06.09 11:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Правда что ли? У Aggrgate<> нет никакого изменяемого состояния.

...
S>Судя по этому примеру, ты не вполне понимаешь, что такое ФП. string.Replace — 100% функциональна. У неё нет побочных эффектов!
Тоха, брось — это не лечится.. =)
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[16]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 23.06.09 11:38
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>имеет к a) Linq2Objects б) IEnumerable ц) дизайну языка C#

б) Все Extension methods для IEnumerable задумывались, как не имеющие побочных эффектов.
a) Все эти методы используются в Linq2Objects.
c) Это все часть дизайна языка, так как Linq2Objects — часть языка.
Все вышеизложенное вместе, создает некие привычные паттерны и семантику операторов работы с множествами, твой же библиотечный метод это все нарушает, что затрудняет чтение и понимание твоего кода.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[15]: LINQ & Except
От: Воронков Василий Россия  
Дата: 23.06.09 12:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

ВВ>>Это ты сам сейчас придумал.

S>Нет. Читать здесь.
S>Покажи мне применение ForEach, в котором нет побочных эффектов.

Я уже показал.

S>pure function без возвращаемого значения эквивалентна {}. Это знают даже падаваны, а уж настоящим джедаям это положено знать — иначе лайтсабер никто не даст.


ThrowIfCollectionIsEmpty — это чистая функция. И да, в идеальном случае она должна быть эквивалента {}, как ты выражаешься, в чем я не вижу никакой проблемы.

S>Можно в студию пример ленивого форича?


var x = list.ForEach(action, condition);


ВВ>>Даю хинт — никто не запрещает в чистых функциях генерировать исключения.

S>Это и будет побочным эффектом.

А вот это уже ты сейчас сам придумал. Никогда, в ни в одном известном мне функциональном языке чистота функций не означает запрет на генерацию исключений. Это даже падаваны знают

ВВ>>А вообще причем тут побочные эффекты и проч.? Не нравится использовать замыкания для побочных эффектов? А каллбеки вообще можно использовать? К чему суть спора сводится-то?

S>К тому, что некоторые люди не могут понять простую и короткую статью даже после многократного прочтения. Больше никакой сути в споре нету.

Некоторым людям функциональное программирование как-то очень сильно на мозги повлияло. О функциональном программировании речи не было вообще. И нет абсолютно никаких проблем в том, что создавать побочные эффекты через замыкания — на то они и *замыкания* мляха — и все, что тут постоянно говорится в ответ, это какие-то максималистские рассуждения по поводу липертовского "мне не нравится".
Свое мнение есть, товарищ? Или вся работа мысли сводится к тому, что повсюду "страшные" подобочные эффекты мерещатся?
Re[16]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 03:57
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я уже показал.

Не вижу.

S>>Можно в студию пример ленивого форича?


ВВ>
ВВ>var x = list.ForEach(action, condition);
ВВ>

Какого типа будет x? Какова семантика этого ForEach? Выполняется ли action до condition или после? Что ты собираешься делать с этим x? Что будет при вызове list.ForEach(action1, condition1).ForEach(action2, condition2) — кто будет вызываться вперёд, action1 или action2?
Ты делаешь всё более плохие предложения.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 03:57
Оценка:
Здравствуйте, _FRED_, Вы писали:


_FR>Какое отношение этот вот метод

_FR>
_FR>  static class Sequence
_FR>  {
_FR>    public static void ForEach<TSource>(this IEnumerable<TSource> source, Action<TSource> action) {
_FR>      foreach(var item in source) {
_FR>        action(item);
_FR>      }//for
_FR>    }
_FR>  }
_FR>

_FR>имеет к a) Linq2Objects б) IEnumerable ц) дизайну языка C#
а) Linq2Objects и есть набор екстеншнов для IEnumerable.
б) IEnumerable выступает жертвой этого метода — см. первый аргумент
ц) к дизайну языка имеет отношение Эрик Липперт — путём непосредственного личного участия. Против того, чтобы вы стреляли себе в ногу такими методами, он не возражает. Он возражает против внедрения такого метода в стандартную библиотеку, в отрыве от которой язык рассматривать нельзя.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 03:57
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Не все множества одинаковы. И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?

_FR>Или же, специализированные множества (List<>, Array) всё-таки могут иметь свои особые "операции" ForEach, RemoveAll и т.п.?
Конечно могут. Их специализированность — в том, что они Mutable. Базовая библиотека предлагает набор чистых операций над immutable объектами.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 05:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

_FR>>имеет к a) Linq2Objects б) IEnumerable ц) дизайну языка C#

S>а) Linq2Objects и есть набор екстеншнов для IEnumerable.

То есть правильно ли я понимаю, что в твоём видении, любой, даже user defined, метод-расширение для IEnumerable можно причислить к Linq2Objects?

S>б) IEnumerable выступает жертвой этого метода — см. первый аргумент


Первый — это слова Эрика о том, что ему "не нравится метод для спецэфектов"? Или слова Ивана
Автор: IB
Дата: 11.06.09
о том, "что вся работа с последовательностями дизайнилась в функциональном стиле, а такой метод этот стиль нарушает."?

Между прочим, не могу не заметить, что вы упорно не отвечаете на вопрос о месте трюка, на который ты сам дал ссылку На сколько он отвечает всем выдвигаемым вами требованиям к методам-расширениям к "последовательностям"? И, если не отвечает, имеет ли он право на существование?

S>ц) к дизайну языка имеет отношение Эрик Липперт — путём непосредственного личного участия. Против того, чтобы вы стреляли себе в ногу такими методами, он не возражает. Он возражает против внедрения такого метода в стандартную библиотеку, в отрыве от которой язык рассматривать нельзя.



Хорошо, тогда скажи, имеет ли хоть смысл держать такой метод в проекте ни C++/CLI? Boo и других языках, что существуют в платформе? Можешь ли ты предположить, что может существовать язык, в котором такой метод имело бы смысл иметь и где такой метод небыл бы "выстрелом себе в ногу"?
Help will always be given at Hogwarts to those who ask for it.
Re[19]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 05:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

_FR>>Не все множества одинаковы. И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?

_FR>>Или же, специализированные множества (List<>, Array) всё-таки могут иметь свои особые "операции" ForEach, RemoveAll и т.п.?
S>Конечно могут. Их специализированность — в том, что они Mutable. Базовая библиотека предлагает набор чистых операций над immutable объектами.

Надеюсь, Иван придерживается того же мнения Потому что я хотел рассмотреть это вот
Автор: IB
Дата: 11.06.09
его утверждение:

2. Выразительности такой код не добавит, а наоборот, запутает и, плюс к этому, "добавляет семантику замыкания, потенциально внося тонкие изменения в жизненные циклы объектов." То есть, реально, такой метод ухудшает имеющийся оператор foreach, добавляя малопредсказуемые побочные эффекты.


Не кажется ли вам (обоим), что применительно к Array.ForEach и List<>.ForEach этот аргумент так же можно применить? Какой выразительности добавляет, например, Array.ForEach, которой не будет у IEnumerable.ForEach, При этом, обращаю специальное внимание, мы читаем код, в котором типы вовсе могут быть не указаны:
var items = GetItems();
items.ForEach(DoSmth);

Почему это, в случае когда GetItems(); возвращает Array или List<> данный код лишён указанных Эриком и Иваном недостатков, а вот когда тип возвращаемого значения IEnumerable — они, недостатки, начинают мешать и дизайну и чтению?

Между прочим, а для IList<> и ICollection<> будут ли уместны расширения ForEach<>, раз уж расширение для List<> уместно?

Собственно, я понял бы точку зрения Ивана, если бы он ответил на мой вопрос, сказав, что метод ForEach вообще не применим не под каким соусом, ибо
Автор: IB
Дата: 11.06.09

plain foreach — чище, очевиднее и понятнее любого метода с Action<T> в качестве аргумента, я не понимаю, какие тут вообще могут быть сомнения..

+
Пресловутые сложности в отладке, которые так же упомянул Эрик — разве они исчезают для Array и List<>.

А вот твою точку зрения я ещё не до конца понимаю
Help will always be given at Hogwarts to those who ask for it.
Re[18]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 05:56
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>То есть правильно ли я понимаю, что в твоём видении, любой, даже user defined, метод-расширение для IEnumerable можно причислить к Linq2Objects?

В принципе — да. Потому, что с точки зрения применения, они ничуть не отличаются. Мы всё еще помним о том, что код редко пишется и часто читается?
Что должен думать читатель, напоровшись на строчку, в которой ForEach перемешан с Where? Весь опыт применения стандартных екстеншнов учит его, что они ленивы и безопасны.
_FR>Первый — это слова Эрика о том, что ему "не нравится метод для спецэфектов"?
это тот аргумент, который помечен this

_FR>Между прочим, не могу не заметить, что вы упорно не отвечаете на вопрос о месте трюка, на который ты сам дал ссылку

Оппа. Что-то где-то глюкает — у меня уже пара ответов обрезалась. По поводу этого трюка поясняю следующее:
Он намеренно вводит семантику побочных эффектов в изначально чистую структуру — для того, чтобы сторонний наблюдатель мог разобраться, в какую императивную программу превращается декларативное описание. Заметь, что Барт не предлагает использовать это в боевых проектах — это отладка.

_FR>Хорошо, тогда скажи, имеет ли хоть смысл держать такой метод в проекте ни C++/CLI? Boo и других языках, что существуют в платформе? Можешь ли ты предположить, что может существовать язык, в котором такой метод имело бы смысл иметь и где такой метод небыл бы "выстрелом себе в ногу"?

Конечно могу. Если у нас есть язык, в котором нет встроенного foreach, то метод ForEach был бы прекрасным его замещением. Точно так же, как и самопальные Using и Lock.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 06:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Что должен думать читатель, напоровшись на строчку, в которой ForEach перемешан с Where? Весь опыт применения стандартных екстеншнов учит его, что они ленивы и безопасны.


На счёт — ленивы, это ты поторопился Например, Count, тот же Aggregate или Except, даже Any и All не ленивы. Остаются вопросы безопастности. Теперь вспомним, что ForEach<> не имеет возвращаемого значения. Что может означать следующий вызов (если мы используем "опыт применения стандартных екстеншнов"):
// Какой-то код
items.ForEach(someParameter); // (1)
// Какой-то ещё код

Например некоторые языки не позволят случайно пропустить возвращаемое значение, и мы не будем рассматривать ситуацию, когда кто-то просто позвал
items.Where(someParameter);
items.Count(someParameter);

Как можно трактовать вызов (1), что бы не придти к выводу о том, что метод имеет "спецэффекты"?

Теперь рассмотрим такой код:
// Какой-то код
SomeMethod(items);
// Какой-то ещё код

Здесь ничего не ясно о том, имеет ли метод "спецэфекты", однако разве можно прожить без таких методов? Но, учтём и это для следующего:

Правильно ли (и на сколько точно?) тогда я сформулирую вашу мысль, сказав, что она заключается в следующем:

Не стоит иметь методы-расширения для IEnumerable, которые имеют "спецэффекты"

или, другими словами,

Методы, обрабатывающие последовательности IEnumerable со спецэффектами не должны быть методами-расширениями для IEnumerable



_FR>>Первый — это слова Эрика о том, что ему "не нравится метод для спецэфектов"?

S>это тот аргумент, который помечен this


_FR>>Между прочим, не могу не заметить, что вы упорно не отвечаете на вопрос о месте трюка, на который ты сам дал ссылку

S>Оппа. Что-то где-то глюкает — у меня уже пара ответов обрезалась. По поводу этого трюка поясняю следующее:
S>Он намеренно вводит семантику побочных эффектов в изначально чистую структуру — для того, чтобы сторонний наблюдатель мог разобраться, в какую императивную программу превращается декларативное описание. Заметь, что Барт не предлагает использовать это в боевых проектах — это отладка.

Ага, то есть отладка в боевом проекте — это не правильно? В релизном коде этому не место — согласен, а "в боевом проекте" — почему нет? С соответствующими #ifdef и [Conditional].

Тогда сведём вопрос к следующему: может ли вообще существовать удобный и практичный метод-расширение для IEnumerable<>? Или его просто не следует делать расширением, ибо "Что должен думать читатель, напоровшись на строчку, в которой ForEach перемешан с Where?"?.

_FR>>Хорошо, тогда скажи, имеет ли хоть смысл держать такой метод в проекте ни C++/CLI? Boo и других языках, что существуют в платформе? Можешь ли ты предположить, что может существовать язык, в котором такой метод имело бы смысл иметь и где такой метод небыл бы "выстрелом себе в ногу"?

S>Конечно могу. Если у нас есть язык, в котором нет встроенного foreach, то метод ForEach был бы прекрасным его замещением. Точно так же, как и самопальные Using и Lock.

Отлично, тогда в стандартной библиотеке вполне может быть метод ForEach, поскольку стандартная библиотека общая на платформаму?
Help will always be given at Hogwarts to those who ask for it.
Re[17]: LINQ & Except
От: Воронков Василий Россия  
Дата: 24.06.09 08:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Какого типа будет x? Какова семантика этого ForEach? Выполняется ли action до condition или после? Что ты собираешься делать с этим x?


Для того, чтобы сделать ForEach ленивым достаточно просто превратить его в итератор. Кстати, в этом может быть даже смысл Если мы хотим к примеру сделать действие пошаговым — выполнили действие, ждем подтверждения от пользователя, идти дальше или нет — как, к примеру, поиск в текстовом редакторе с кнопочкой Next. А если пользователь нажмет кнопочку Close, то нам и по всей последовательности пробегаться не придется.

Так что все просто. Обычный ForEach:

static IEnumerable<Int32> ForEach(this IEnumerable<Int32> self, Func<Int32,Boolean> cond, Action<Int32> act)
{
    foreach (var i in self)
        if (condition(i))
            action(i);
}


Ленивый ForEach:

static IEnumerable<Int32> ForEach(this IEnumerable<Int32> self, Func<Int32,Boolean> cond, Action<Int32> act)
{
  foreach (var i in self)
     if (condition(i))
     {
       action(i);
       yield return i;
     }
}


S>Что будет при вызове list.ForEach(action1, condition1).ForEach(action2, condition2) — кто будет вызываться вперёд, action1 или action2?


А это ты уже сам проверь

var it = arr.ForEach(i => i < 2, Console.WriteLine).ForEach(i => i < 3, Console.WriteLine);


Кстати, раз уж зашел такой разговор, объясни мне теперь как ты себе представляешь себе ленивой функцию:

T Aggregate<T>(this IEnumerable<T> self, Func<T,T,T> func);


Очень интересно будет послушать


S>Ты делаешь всё более плохие предложения.


Согласен
Суть-то конечно не в том, чтобы ForEach превращать в ленивую чистую и светлую функцию. Ленивая — ну может иногда это имеет смысл. Чистая — ну может практически никогда Ну и что с того? Вот вернемся к Aggregate. У меня половина использований этой ф-ции может иметь побочные эффекты. А знаешь почему? Потому что 1) агрегаты сложные, может быть несколько аккумуляторов, сложное состояние 2) побочные эффекты с замыканиями получить легко и удобно, ага. Потому что лямбды при всей своей как бы "функциональности" на самом деле деле таят в себе грубую и жестокую императивщину — независимо от того, из одного ли или нескольких экспрешионов они состоят. Ну например:

int y = 0;            
Func<Int32,Int32> f = x => y += x;


Ведь не убрали же "тонкую семантику замыкания" из лямбд почему-то. А это значит, что любая функция, принимающая замыкания, потенциально может иметь побочные эффекты. Тчк. И ForEach тут не исключение. Он просто... ну "чуть больше" склоняет нас к тому, чтобы сотворить побочные эффекты, чем тот же Aggregate.

Но это даже и неважно. Пусть ForEach у нас целиком "побочный" и неленивый. Ты объясни мне, что в этой функции такого, что надо с пеной у рта и кулаками доказывать, что она не нужна, вносит там всякое непонятно что и вообще зло в чистом виде, а? Липерт, которого ты переводил, написал, повторюсь:

1. В библиотеке System.Core этой функции нет и нечего ей там делать (с чем я абсолютно согласен).
2. Ему лично *с философской точки зрения* эта функция не нравится, но если вам нравится — напишите ее сами.

Все. После этого некоторые товарищи решили это самое "философское не нравится" превратить в какую-то догму. А нафига? Мнение Липерта закон? Странно вот получается, на Фаулера с Эвансом вам насрать, а Липерт — уже икона.
Re[18]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 08:34
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Все имеющиеся — да сколько угодно. На счёт всех остальных — не понятно для чего.

Ты о чем?

_FR>Вот например такой артефакт имеет право на существование или нет? Как он соотносится с тем, что по твоим словам "задумывалось"?

Тебе на это Синклер уже ответил.

_FR>Я говорил про конкретно один мой собственный метод.

Я про него же.

_FR> Как Linq2Objects может его использовать?

Ему не обязательно его использовать, важно, что он определяет культуру и стиль работы с коллекциями.
Ты, безусловно можешь это нарушить, в своих библиотеках и приложениях, но с моей точки зрения — это кривизна с четко видимым радиусом.

_FR>Можешь ли ты дать определение того, что является "Linq2Objects" что бы мы могли удостовериться, что говорим об одном и том же?

Это расширение языка для построения декларативных запросов к объектам реализующим IEnumerable.

_FR>Какого именно языка?

В данном случае (для простоты) C#, так как речь идет именно о нем. Другие, в данном контексте, меня не интересуют.

_FR> И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?

Никто не призывает тебя ограничивать — расширяй сколько угодно, но не нарушай привычную семантику. Или расширяй другим образом. Например, против метода FredsLibrary.ForEach<T>(IEnumerable<T> source, Action<T> action) — никто не возражает.

_FR>Тут я не соглашусь,

Твое право.

_FR>ибо семантика моего метода отлична от "всех остальных" (нету возвращаемого значения). С какой это стати операции, имеющие различные семантики нужно рассматривать вместе?

Вот именно, и поэтому для твоей семантики место в другом месте, уж прости за тафталогию. Это же место, зарезервировано за операторами без побочных эффектов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[18]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 08:34
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>так всетаки дело в том, что он метод ForEach расширяющий?

Именно, Василий.. =)

А>ок, чем плох тот же самый метод но в виде простой статической функции?

Ну, например тем, что он совершенно бесполезен, и опять-таки ясности коду не добавит, если он имеет ту же семантику обычного foreach. Скажем, против метода Parallel.ForEach<T> — вообще никаких возражений нет — сразу видно, что это ни разу не обычный foreach, со своей логикой, которая, к тому же, очевидна из названия класса.
Почему-то им не пришло в голову делать extension method ParallelForEach<T>(this IEnumerable...)

А>почему все кто "читал липерта" навязывают оператор foreach?

С чего ты взял, что кто-то чего-то навязывает?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[19]: LINQ & Except
От: Воронков Василий Россия  
Дата: 24.06.09 08:54
Оценка:
Здравствуйте, IB, Вы писали:

А>>так всетаки дело в том, что он метод ForEach расширяющий?

IB>Именно, Василий.. =)

[offtopic]
Мне вот интересно, а на основе каких умозаключений, ты делаешь вывод, что Аноним — это я? Может, я тогда и остальную твою логику пойму
Под анонимом заходят, чтобы написать:
1. Глупость
2. Хамство
3. Высказать свое мнение "несмотря ни на что", даже если оно противоречит "политике партии".
Я все это делаю под своим ником, зачем мне еще Аноним?
[/offtopic]
Re[19]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 08:56
Оценка:
Здравствуйте, IB, Вы писали:

_FR>>Все имеющиеся — да сколько угодно. На счёт всех остальных — не понятно для чего.

IB>Ты о чем?

Все Extension methods для IEnumerable задумывались, как не имеющие побочных эффектов.


Странно, что "Все Extension methods для IEnumerable", даже те, которые я сам собираюсь написать, кем-то уже "задумывались"

_FR>> Как Linq2Objects может его использовать?

IB>Ему не обязательно его использовать, важно, что он определяет культуру и стиль работы с коллекциями.
IB>Ты, безусловно можешь это нарушить, в своих библиотеках и приложениях, но с моей точки зрения — это кривизна с четко видимым радиусом.

Я пытаюсь определить величину этого радиуса. Что "есть кривизна"? Правильно ли я её вывел здесь
Автор: _FRED_
Дата: 24.06.09
? Или нет?

_FR>>Можешь ли ты дать определение того, что является "Linq2Objects" что бы мы могли удостовериться, что говорим об одном и том же?

IB>Это расширение языка для построения декларативных запросов к объектам реализующим IEnumerable.

С точки зрения языка C# является ли метод Count() или Any() "Linq2Objects" или нет? Если следовать твоему определению, то нет. Тогда и ForEach() не имеет отношение к "Linq2Objects" так как не связан с "расширение языка для построения декларативных запросов…". Правильно?

_FR>>Какого именно языка?

IB>В данном случае (для простоты) C#, так как речь идет именно о нем. Другие, в данном контексте, меня не интересуют.

Хорошо, давай тогда разделим вопрос: о необходимости метода ForEach() в стандартной библиотеке и практике его использования в C#. От ответа на первую часть ты, я так понимаю, хотел бы уклониться, потому что тебя это не интересует? Хорошо, больше не буду на эту тему спрашивать, сосредоточусь на второй части.

_FR>> И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?

IB>Никто не призывает тебя ограничивать — расширяй сколько угодно, но не нарушай привычную семантику. Или расширяй другим образом. Например, против метода FredsLibrary.ForEach<T>(IEnumerable<T> source, Action<T> action) — никто не возражает.

Ну а как-же это я или кто-другой мог понять из твоих слов здесь
Автор: IB
Дата: 11.06.09
Вот поэтому я и прошу лишь точнее сформулировать вас вашу же точку на данный вопрос.

_FR>>ибо семантика моего метода отлична от "всех остальных" (нету возвращаемого значения). С какой это стати операции, имеющие различные семантики нужно рассматривать вместе?

IB>Вот именно, и поэтому для твоей семантики место в другом месте, уж прости за тафталогию. Это же место, зарезервировано за операторами без побочных эффектов.

Какое? Этим местом является метод-расширение для IEnumerable или что-то ещё?
Help will always be given at Hogwarts to those who ask for it.
Re[20]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 09:17
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Странно, что "Все Extension methods для IEnumerable", даже те, которые я сам собираюсь написать, кем-то уже "задумывались"

Задумывались не методы, а идеология. Сам ты можешь писать что угодно, но то, что ты напишешь либо укладывается в принятый стиль, либо нет. Конкретно extension method ForEach для IEnumerable — не укладывается. Еще вопросы?

_FR>Я пытаюсь определить величину этого радиуса.

У меня есть ощущение, что ты прекрасно все понял, но так как у тебя уже есть свой ForEach и ты очень не хочешь от него отказываться, то тебе просто очень хочется до чего-нибудь докопаться.

_FR> Тогда и ForEach() не имеет отношение к "Linq2Objects" так как не связан с "расширение языка для построения декларативных запросов…". Правильно?

Нет, не правильно. Еще раз перечитай мой предыдущий пост, там где говорится о том, что L2O не обязательно должен использовать все методы расширения.

_FR>Хорошо, давай тогда разделим вопрос: о необходимости метода ForEach() в стандартной библиотеке и практике его использования в C#. От ответа на первую часть ты, я так понимаю, хотел бы уклониться, потому что тебя это не интересует?

Относительно метода ForEach в стандартной библиотеке и так никаких несогласных мнений нет, так что непонятно зачем ты тут его вообще вспомнил.

_FR>Ну а как-же это я или кто-другой мог понять из твоих слов здесь
Автор: IB
Дата: 11.06.09

А что там непонятного? Возражения возникли только у тебя и у Василия и то, ровно по тому, что вы ратуете конкретно за extension method, так что не надо теперь передергивать и ратовать за точность формулировок.

_FR>Вот поэтому я и прошу лишь точнее сформулировать вас вашу же точку на данный вопрос.

Точнее уже некуда и так все разжевали что могли.

_FR>Какое? Этим местом является метод-расширение для IEnumerable или что-то ещё?

Тебе в восьмой раз повторить?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[20]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 09:17
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Под анонимом заходят, чтобы написать:

ВВ>1. Глупость
ВВ>2. Хамство
ВВ>3. Высказать свое мнение "несмотря ни на что", даже если оно противоречит "политике партии".
Даже тебе, не всегда хватает смелости сделать все это под своим ником..
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[21]: LINQ & Except
От: Воронков Василий Россия  
Дата: 24.06.09 09:25
Оценка:
Здравствуйте, IB, Вы писали:

IB>Даже тебе, не всегда хватает смелости сделать все это под своим ником..


Т.е., несмотря ни на что, я тебе все равно являюсь под образом анонима?

Понял. Мешать не буду. Развлекайтесь.
Re[20]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 09:33
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>я не Василий , но ты можешь звать меня Хозяин (с большой буквы пожалуйста)

Хорошо, Клоун..

А>пример некорректен.

Он более чем корректен. Он очень точно показывает место всех подобных методов.

A>потому что это принципиально другой foreach.

То есть, если foreach принципиально другой, то в extension methods не годится, а если не принципиально, то годится?
Критерий принципиальности можно узнать?

А>семантика расширяющего метода кроме прочего заключается в видимости "собственного" ForEach у разных последовательностей, особая обработка которых может быть инкапсулированна в этом методе

Ну, хорошо, конечно, что ты это понимаешь. Так почему ParallelForEach, не может иметь такую семантику?

А>читай ветку внимательно

Да уж, приз самого внимательного читателя ты заработал. Тебя не затруднит показать, в каком месте тебе что-то навязали?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[20]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 09:38
Оценка:
Здравствуйте, _FRED_, Вы писали:
_FR>На счёт — ленивы, это ты поторопился Например, Count, тот же Aggregate или Except, даже Any и All не ленивы.
Ок. Но они тем не менее не имеют побочных эффектов.

_FR>Остаются вопросы безопастности. Теперь вспомним, что ForEach<> не имеет возвращаемого значения. Что может означать следующий вызов (если мы используем "опыт применения стандартных екстеншнов"):

_FR>
_FR>// Какой-то код
_FR>items.ForEach(someParameter); // (1)
_FR>// Какой-то ещё код
_FR>

Да. Остаётся именно такой вопрос. Что может означать этот вызов?
_FR>Как можно трактовать вызов (1), что бы не придти к выводу о том, что метод имеет "спецэффекты"?
Да, мы заподозрим, что ничего, кроме спецэффектов, метод не делает. Но всё время будет мучить мысль: а что еще делает ForEach, кроме того же foreach?

_FR>Теперь рассмотрим такой код:

_FR>
_FR>// Какой-то код
_FR>SomeMethod(items);
_FR>// Какой-то ещё код
_FR>

_FR>Здесь ничего не ясно о том, имеет ли метод "спецэфекты", однако разве можно прожить без таких методов?
Ну, наверное в целом нельзя.

_FR>Правильно ли (и на сколько точно?) тогда я сформулирую вашу мысль, сказав, что она заключается в следующем:

_FR>

Не стоит иметь методы-расширения для IEnumerable, которые имеют "спецэффекты"

_FR>или, другими словами,
_FR>

Методы, обрабатывающие последовательности IEnumerable со спецэффектами не должны быть методами-расширениями для IEnumerable

_FR>
Да.

_FR>Ага, то есть отладка в боевом проекте — это не правильно?

Ну да. Кагбэ лично я бы удивился, если бы некий продукт вдруг начал валить в консоль тонны отладочного мусора.

_FR>В релизном коде этому не место — согласен, а "в боевом проекте" — почему нет? С соответствующими #ifdef и [Conditional].

Да, я имел в виду именно в релизном. То есть строить основную функциональность на вот таких штуках не стоит.

_FR>Тогда сведём вопрос к следующему: может ли вообще существовать удобный и практичный метод-расширение для IEnumerable<>? Или его просто не следует делать расширением, ибо "Что должен думать читатель, напоровшись на строчку, в которой ForEach перемешан с Where?"?.

Может. Большое количество удобных и практичных методов-расширений приведено в классе Enumerable.

_FR>Отлично, тогда в стандартной библиотеке вполне может быть метод ForEach, поскольку стандартная библиотека общая на платформаму?

Нежелательно — библиотека будет всовывать такие методы и в языки, где ForEach уже есть. Лучше внести это в библиотеку, поставляемую в комплекте с языком.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: LINQ & Except
От: Аноним  
Дата: 24.06.09 09:39
Оценка:
Здравствуйте, IB, Вы писали:

IB>Он более чем корректен. Он очень точно показывает место всех подобных методов.

нет некорректен, он абсолютно ничего не показывает

A>>потому что это принципиально другой foreach.

IB>То есть, если foreach принципиально другой, то в extension methods не годится, а если не принципиально, то годится?
IB>Критерий принципиальности можно узнать?
ну это элементарно, ознакомься что ли с этой библиотекой, потом сравни с, ну хотя бы, List.ForEach

IB>Да уж, приз самого внимательного читателя ты заработал. Тебя не затруднит показать, в каком месте тебе что-то навязали?

ты забыл сказать пожалуйста, дурачок
Re[21]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 09:40
Оценка:
Здравствуйте, IB, Вы писали:

_FR>>Какое? Этим местом является метод-расширение для IEnumerable или что-то ещё?

IB>Тебе в восьмой раз повторить?

Скажи один раз — точна ли и полна ли такая формулировка:

Любой метод-расширение для IЕnumerable не должен иметь сторонних эффектов


Я этот вопрос уже в четвёртый раз задаю, а ответа не вижу
Help will always be given at Hogwarts to those who ask for it.
Re[20]: LINQ & Except
От: Воронков Василий Россия  
Дата: 24.06.09 09:44
Оценка:
Здравствуйте, _FRED_, Вы писали:

Чувак, на самом деле их точка зрения сейчас более или менее сформировалась и стала понятной. Я бы ее сформулировал так:
Исходя из того, что

1) IEnumerable предоставляет собой read-only forward-only модель работы с последовательностью, и
2) LINQ реализован в качестве методов расширений для IEnumerable

все последующие расширения для IEnumerable должны следовать "стилю" LINQ (а может быть, даже будут считаться своего рода "расширением" linq2objects).

Липпертом тут уже и не пахнет. Мнение, так сказать, авторское Более того, возможностей опровергнуть, что это утверждение является истинным, ничуть не больше, чем возможностей это доказать.
Так можно бесконечно по кругу ходить
Re[21]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 09:51
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _FRED_, Вы писали:

_FR>>На счёт — ленивы, это ты поторопился Например, Count, тот же Aggregate или Except, даже Any и All не ленивы.
S>Ок. Но они тем не менее не имеют побочных эффектов.

Спасибо за этот и следующие конкретные ответы.

_FR>>items.ForEach(someParameter); // (1)

S>Да. Остаётся именно такой вопрос. Что может означать этот вызов?
_FR>>Как можно трактовать вызов (1), что бы не придти к выводу о том, что метод имеет "спецэффекты"?
S>Да, мы заподозрим, что ничего, кроме спецэффектов, метод не делает.

Так как нету альтернатив (по крайней мере я не могу выдумать, да и ты не привёл), мы поймём, "что ничего, кроме спецэффектов, метод не делает".

S>Но всё время будет мучить мысль: а что еще делает ForEach, кроме того же foreach?


Это уже вопрос именования метода. Методов, которые в своём имени не могут конкретно сказать, что они делают и так полно.

_FR>>Правильно ли (и на сколько точно?) тогда я сформулирую вашу мысль, сказав, что она заключается в следующем:


S>Да.

Наконец-то Ты не знаешь, у Ивана такое же мнение? А то мне он не отвечает

_FR>>Тогда сведём вопрос к следующему: может ли вообще существовать удобный и практичный метод-расширение для IEnumerable<>? Или его просто не следует делать расширением, ибо "Что должен думать читатель, напоровшись на строчку, в которой ForEach перемешан с Where?"?.

S>Может. Большое количество удобных и практичных методов-расширений приведено в классе Enumerable.

Я забыл вставить самое главное

удобный и практичный "не чистый, со спец-эффектами" метод-расширение для IEnumerable<>


Может или нет?
Help will always be given at Hogwarts to those who ask for it.
Re[20]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 09:56
Оценка:
Здравствуйте, <Аноним>, Вы писали:
А>я не Василий , но ты можешь звать меня Хозяин (с большой буквы пожалуйста)
Сразу после твоей регистрации под этим ником сие будет выполняться автоматически.

А>пример некорректен. потому что это принципиально другой foreach. именно поэтому он у них в своем статическом классе название которого отражает суть обработки.

А зачем тебе "принципиально такой же" foreach? Если твой тоже "принципиально другой", то по тем же соображениям он должен быть "в своем статическом классе название которого отражает суть обработки".

А>семантика расширяющего метода кроме прочего заключается в видимости "собственного" ForEach у разных последовательностей, особая обработка которых может быть инкапсулированна в этом методе.

А вот это, кстати, первое осмысленное соображение в пользу такого ForEach.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 09:59
Оценка:
Здравствуйте, Ziaw, Вы писали:

_FR>>Скажи один раз — точна ли и полна ли такая формулировка:

_FR>>

Любой метод-расширение для IЕnumerable не должен иметь сторонних эффектов


Z>Не точна, т.к. замыкания позволяют создавать побочные эффекты очень легко. Но это не повод писать методы единственной целью которых является создание побочных эффектов.


Будь добр, приведи точную формулировку.
Help will always be given at Hogwarts to those who ask for it.
Re[19]: LINQ & Except
От: Воронков Василий Россия  
Дата: 24.06.09 10:02
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это не будет компилироваться. Ты, наверное, имел в виду static void?


Да.

S>Ок, хорошо. А что насчёт else?


А что насчет else? Семантика данного метода else не предполагает.

S>А почему сначала action, а потом yield return i?


Потому что если будет наоборот, то получится просто неправильный код. Работающий некорректно.
Я тебе привел пример когда ленивый ForEach может быть актуален — нам нужно просто пройтись по коллекций по шагам, с возможностью остановиться в любой момент. Поменяй местами yield и action и твой код просто перестанет работать:

it.GetEnumerator().MoveNext();

— а дальше не пошли. Результат: action не вызван.

ВВ>>А это ты уже сам проверь

S>Что значит "сам проверь"??? Я не хочу читать код, в котором куда ни ткни — везде "сам проверь"!
S>Без обращения к исходникам невозможно догадаться, будет ли yield делаться перед action или после. Из-за этого могут случиться совершенно произвольные комбинации побочных эффектов.

Ты уж извини, но если немножко подумать, то можно. А вопрос что там будет раньше выполнено, action1 или action2, это к чему было? Работать это все будет также как любой итератор. Так что да, если тебе непонятно, то сам и проверяй:

var arr = new int[]{ 1, 1, 1, 2, 2, 2, 3, 3, 3};            
var it = arr.ForEach(i => i < 2, Console.WriteLine).ForEach(i => i < 3, Console.WriteLine);


ВВ>>
ВВ>>var it = arr.ForEach(i => i < 2, Console.WriteLine).ForEach(i => i < 3, Console.WriteLine);
ВВ>>

S>А можно какой-нибудь более реалистичный пример?
S>И, желательно, законченный — в том смысле, чтобы было видно, в какой именно момент всё таки вызываются итераторы. Я имею в виду — что ты собираешься делать дальше с этим it? Как ты будешь его применять? Что можно сделать с ним полезного, кроме как тупо зафигачить foreach?

Я тебе дал пример — действие нужно выполнять *пошагово*. Мы не знаем — нужно ли нам проходить по всей последовательности. Пользователь жамкнет Next, пойдем дальше. Нет, так нет.

S>Представляю себе примерно вот такой:

S>
S>Func<T> Aggregate<T> (this IEnumerable<T> self, Func<T, T, T> aggregate)
S>

S>) Тело сам угадаешь, или надо написать?

А куда стандартная делась? Или теперь ленивость уже не является таким важным признаком?

S>Да. Но основная цель Aggregate — всё-таки не побочные эффекты, а таки вычисление результата. Более того, скорее всего окажется, что в реальном проекте ты сам постараешься свести побочные эффекты к минимуму — потому, что скармливание чистых функций в Aggregate, к примеру, позволит безопасно раскидать его по нескольким ядрам.


Основная цель ForEach — выполнить действие. Действие может иметь побочные эффекты. Да, пусть вероятность наличия побочных эффектов в данном действии 99 к 1 — но мы же не вероятность обсуждаем, а дизайн?
И вот by design отличия между Aggregate и ForEach не такие уж принципиальные.

S>"чуть больше" — это, должно быть, шутка. Приведи мне пример реального аргумента, который ты бы скормил в ForEach в реальном проекте, и чтобы он не имел побочных эффектов. Ок, выброс исключения мы побочными эффектами считать не станем.


Ок, чуть больше, чем просто чуть больше.
Пример "чистого" ForEach — валидация последовательности: элементы последовательности должны удовлетворять некоторому условию, если не удовлетворяют — генерируем исключение.

S>Я как бы тоже не стану бегать за вами с бензопилой и проверять, нет ли у вас там форича для IEnumerable.


А в чем смысл дискуссии тогда? Доказать, что все расширения для IEnumerable должны придерживаться функционального стиля? Не должны нарушать стиль Linq2objects? Это какой-то ваш собственный аргумент и весьма не бесспорный. Я бы сказал, это больше похоже на кодинг стандарт, который вы тут пытаетесь доказывать.

ВВ>>А нафига? Мнение Липерта закон? Странно вот получается, на Фаулера с Эвансом вам насрать, а Липерт — уже икона.

S>Ничего странного. Фаулер пишет пургу, а Липперт — рулит. Тут как бы не личность первична, а её плоды.

А где Липперт-то рулит, а? Человек, имеющий отношение к языку, в котором лямбды реализованы поверх замыканий, у меня, ты знаешь, как-то автоматически не вызывает большого доверия.
Re[21]: LINQ & Except
От: Аноним  
Дата: 24.06.09 10:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

А>>пример некорректен. потому что это принципиально другой foreach. именно поэтому он у них в своем статическом классе название которого отражает суть обработки.

S> А зачем тебе "принципиально такой же" foreach? Если твой тоже "принципиально другой", то по тем же соображениям он должен быть "в своем статическом классе название которого отражает суть обработки".
принципиально другой означает, что вообще будет работать иначе — а распараллеливание может внести кучу особенностей которые нужно учитывать при использовании таких вот ForEach. я же говорю о другом способе обработки (более оптимальном что ли) в зависимости от последоватености, здесь становится явно видно, что запускается ForEach этой конкретной последователности реализация этой конкретики может быть сделана в будущем. да и вообще все лаконично и законченно в таком вызове

з.ы. удивился, что есть люди с подписью rsdn, в топике, которые не хамят
Re[25]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 10:09
Оценка:
Здравствуйте, Ziaw, Вы писали:

_FR>>Будь добр, приведи точную формулировку.


Z>Не стоит создавать методов расширения IEnumerable<> целью которых является получение побочных эффектов.


Чем же эта формултровка отличается от

Любой метод-расширение для IЕnumerable не должен иметь сторонних эффектов

? На мой взгляд — ничем существенным.
Help will always be given at Hogwarts to those who ask for it.
Re[20]: LINQ & Except
От: Ziaw Россия  
Дата: 24.06.09 10:10
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Пример "чистого" ForEach — валидация последовательности: элементы последовательности должны удовлетворять некоторому условию, если не удовлетворяют — генерируем исключение.


Для этого есть более понятный Any()
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[22]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 10:12
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>нет некорректен, он абсолютно ничего не показывает

А>ну это элементарно, ознакомься что ли с этой библиотекой, потом сравни с, ну хотя бы, List.ForEach
А>ты забыл сказать пожалуйста, дурачок
То есть, по делу сказать нечего? Я так и думал, развлекайся дальше..
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[22]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 10:12
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Скажи один раз — точна ли и полна ли такая формулировка:

_FR>

Любой метод-расширение для IЕnumerable не должен иметь сторонних эффектов

_FR>Я этот вопрос уже в четвёртый раз задаю, а ответа не вижу

Критерии extension methds для IEnumerable были сформулированы еще в блоге Липперта:
"Не стоит делать extension method для IEnumerable, единственным смыслом которого будет достижение побочных эффектов"
ForEach как раз ровно такой и есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[23]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 10:19
Оценка:
Здравствуйте, IB, Вы писали:

IB>Критерии extension methds для IEnumerable были сформулированы еще в блоге Липперта:

IB>"Не стоит делать extension method для IEnumerable, единственным смыслом которого будет достижение побочных эффектов"
IB>ForEach как раз ровно такой и есть.

Можешь ткнуть в цитату на оригинале? Я вижу только:

It does not sit well with me to make the one and only sequence operator that is only useful for its side effects.

и смысл её немного не тот, что в твоей фразе.
Help will always be given at Hogwarts to those who ask for it.
Re[27]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 10:20
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>>>Не стоит создавать методов расширения IEnumerable<> целью которых является получение побочных эффектов.

_FR>>Чем же эта формултровка отличается от

Любой метод-расширение для IЕnumerable не должен иметь сторонних эффектов

? На мой взгляд — ничем существенным.

Z>Тем же чем отличаются два утверждения:
Z>1. Метод написан для получения побочных эффектов.
Z>2. Метод не имеет 100% защиты от получения с его помощью побочных эффектов.

Понял, спасибо.
Help will always be given at Hogwarts to those who ask for it.
Re[21]: LINQ & Except
От: Воронков Василий Россия  
Дата: 24.06.09 10:38
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Для этого есть более понятный Any()


Ну и Aggregate можно вместо ForEach использовать, раз так хочется. Сам видел примеры.
Any мне даст информации об элементе, для которого не выполнилось условие. А если эта информация нужна? В таком случае ForEach будет более удобен.

Вот пример "чистого" ForEach:

class Cargo
{
    public int UniqueId { get; set; }
    
    public int Weight { get; set; }
    
    public bool WeightLimited { get; set; }
}

const int LIMIT = 50;

...

var cargo = new[] { new Cargo { UniqueId = 1, Weight = 150, WeightLimited = true},
    new Cargo { UniqueId = 2, Weight = 100, WeightLimited = false } };
    
cargo.ForEach(c => c.WeightLimited && c.Weight > LIMIT, c => ThrowException(c.UniqueId, c.Weight));
Re[21]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 10:41
Оценка:
Здравствуйте, IB, Вы писали:

Постараюсь точнее определить свою цель, надеюсь, это поможет мне получить интересующие меня ответы.

_FR>>Я пытаюсь определить величину этого радиуса.

IB>У меня есть ощущение, что ты прекрасно все понял,

Я понимаю сам факт и причины того, почему метод ForEach выглядит белой вороной среди всего остального.

IB>но так как у тебя уже есть свой ForEach и ты очень не хочешь от него отказываться, то тебе просто очень хочется до чего-нибудь докопаться.


Я готов от него отказаться и переписать все его вызовы.




Но я хочу понять, каким ещё методам, наравне с ForEach не место в коде на C#.

У Эрика есь своя формулировка:

It does not sit well with me to make the one and only sequence operator that is only useful for its side effects.


у тебя своя:

Не стоит делать extension method для IEnumerable, единственным смыслом которого будет достижение побочных эффектов


В деталях определения различаются, а именно: если я придумаю набор методов для обработки IEnumerable, которые не будут служить _только_ получению побочных эффектов, и которые будет удобно сделать методами-расширениями, то как мне поступить?

Пример того, что такие методы могут быть, уже были и были отвергнуты, как "отладочные". А если придумать что-то такое же, но не отладочное, то как быть? Отказываться от расширений?

Синклер согласился с третьей:

Методы, обрабатывающие последовательности IEnumerable со спецэффектами не должны быть методами-расширениями для IEnumerable


То есть критерием того, делать ли метод расширением является только его "чистота". Можешь ли ты согласиться с этим?
Help will always be given at Hogwarts to those who ask for it.
Re[22]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.06.09 11:04
Оценка:
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Any мне даст информации об элементе, для которого не выполнилось условие. А если эта информация нужна? В таком случае ForEach будет более удобен.
В таком случае foreach будет еще более удобен.
foreach(var c in cargo.Where(c => c.WeightLimited && c.Weight > LIMIT))
  ThrowException(c.UniqueId, c.Weight));
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: LINQ & Except
От: Воронков Василий Россия  
Дата: 24.06.09 11:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>В таком случае foreach будет еще более удобен.

S>
S>foreach(var c in cargo.Where(c => c.WeightLimited && c.Weight > LIMIT))
S>  ThrowException(c.UniqueId, c.Weight));
S>


Таким макаром можно расписать любой ForEach. С помощью дополнительного if-a — расписать любой Where, сказав, что так "чище, более удобно, легче рефакторится" и, кстати, что есть абсолютная правда, легче дебажится. И мы приходим к тому, с чего начинали. Рекурсия получается, нет?

--

IEnumerable<> — это нейтральный тип. Он просто предоставляет контракт, согласно которому по некой последовательности возможен forward-only проход. И все. Данный тип ни к какому стилю не располагает, ни к чему не обязывает и появился, особенно в не-генерик виде, задолго до Линка и прочих радостей.

Когда я подключаю пр-во имен System.Linq, то получаю набор расширений для IEnumerable<>, которые позволяют работать с ним в функциональном *стиле*. Если я подключу пр-во имен Utils.SomeSuperExtensions, то получаю набор расширений, которые вполне могут позволять работать с IEnumerable<> в каком-то более другом стиле. Все очень просто. И никакой путаницы нет.
А если вам так хочется верить, что после System.Linq никто не может к IEnumerable<> и пальцем прикоснуться, не согласовав свои действия лично с IB и Эриком Липпертом, то ради бога, вам никто не запрещает, только делайте это тихо, не смущая остальных своими суевериями.
Re[24]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 11:45
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Можешь ткнуть в цитату на оригинале? Я вижу только:

_FR>

It does not sit well with me to make the one and only sequence operator that is only useful for its side effects.

_FR>и смысл её немного не тот, что в твоей фразе.
А какой? Ты намекаешь на то, что если бы таких операторов было много, то оно было бы ничего? Возможно, но тогда это была бы не бабушка, а дедушка.. =)
Смысл то как раз в том, что остальные sequence operator делают еще что-то и без side effects, и поэтому реализовывать еще один sequence operator единственным предназначением которого являются side effects — не правильно.

Так что смысл как раз тот самый, и я бы не делал акцент на the one and only. Там же, есть еще одна фраза: Clearly the sole purpose of a call to this method is to cause side effects. И это ровно та причина, по которой не соит делать такой extension method для IEnumerable.

Так именно этот момент и вызывал сомнения?
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[22]: LINQ & Except
От: IB Австрия http://rsdn.ru
Дата: 24.06.09 11:45
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Я понимаю сам факт и причины того, почему метод ForEach выглядит белой вороной среди всего остального.

Отлично.

_FR>У Эрика есь своя формулировка:

_FR>

It does not sit well with me to make the one and only sequence operator that is only useful for its side effects.

Я бы не делал акцент на one and only, я бы выделил is only useful for, что ты и сделал в моей цитате... =)

_FR>В деталях определения различаются, а именно: если я придумаю набор методов для обработки IEnumerable, которые не будут служить _только_ получению побочных эффектов, и которые будет удобно сделать методами-расширениями, то как мне поступить?

Если эти методы не будут служить только для получения побочных эффектов, то не важно сколько их будет, их вполне можно сделать методами расширения, если так удобнее.

_FR>Синклер согласился с третьей:

_FR>

Методы, обрабатывающие последовательности IEnumerable со спецэффектами не должны быть методами-расширениями для IEnumerable

_FR>То есть критерием того, делать ли метод расширением является только его "чистота". Можешь ли ты согласиться с этим?
Могу, критерий действительно чистота, а не количество этих методов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[23]: LINQ & Except
От: _FRED_ Черногория
Дата: 24.06.09 13:06
Оценка:
Здравствуйте, IB, Вы писали:

(1)
IB>Если эти методы не будут служить только для получения побочных эффектов, то не важно сколько их будет, их вполне можно сделать методами расширения, если так удобнее.

(2)
_FR>То есть критерием того, делать ли метод расширением является только его "чистота". Можешь ли ты согласиться с этим?
IB>Могу, критерий действительно чистота, а не количество этих методов.

Не могу одновременно понять и первое и второе: из первого следует (если я правильно понял твои слова), что метод расширения IEnumerable имеет право на жизнь если он приносит какую-то ещё пользу помимо совершения побочных эффектов?

(Кстати, ожешь показать пример метода, имеющего побочный эффект, но служащего не "только для получения" этого самого эффекта? Являются ли такими методы Debug и Watch из блога Барта?)

Но второе твоё утверждение говорит, что критерием "делать или не делать расширением является чистота", то есть отсутствие побочных эффектов

Как это можно понять? Так "чистота" (то есть отсутствие побочных эффектов) или "ещё как-то смысл кроме побочных эффектов" должны позволять решить, делать метод расширением или не делать?
Help will always be given at Hogwarts to those who ask for it.
Re[20]: LINQ & Except
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.06.09 02:59
Оценка:
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А что насчет else? Семантика данного метода else не предполагает.
Ага. То есть для else придется вернуться к обычному foreach().

ВВ>Потому что если будет наоборот, то получится просто неправильный код. Работающий некорректно.

C чего ты взял?
ВВ>Я тебе привел пример когда ленивый ForEach может быть актуален — нам нужно просто пройтись по коллекций по шагам, с возможностью остановиться в любой момент.
Нет, ты не привёл этого примера. Может, ты там что-то в голове себе подумал, но твой код ничего этого не показывает.


ВВ>Поменяй местами yield и action и твой код просто перестанет работать:

ВВ>it.GetEnumerator().MoveNext();
ВВ>- а дальше не пошли. Результат: action не вызван.
Это твой код перестанет работать. А мой код, быть может, наоборот хочет уметь прерывать выполнение action до того, как он произойдёт.


ВВ>Ты уж извини, но если немножко подумать, то можно.

Ты уж извини, но как видно, думать надо много.

ВВ>А вопрос что там будет раньше выполнено, action1 или action2, это к чему было?

К тому, что если мы пытаемся получить File Move путём комбинирования File.Copy и File.Delete, то порядок действий, наверное, имеет какое-то значение. Нет?

ВВ>Работать это все будет также как любой итератор.

Это — не любой итератор. Это — плод воспалённого сознания.

ВВ>Так что да, если тебе непонятно, то сам и проверяй:

ВВ>
ВВ>var arr = new int[]{ 1, 1, 1, 2, 2, 2, 3, 3, 3};            
ВВ>var it = arr.ForEach(i => i < 2, Console.WriteLine).ForEach(i => i < 3, Console.WriteLine);
ВВ>

Дальше что? Этот код ничего не делает. На всякий случай намекну, что в нём нет ни одного вызова GetEnumerator().
Кроме того, это вырожденный пример — ясно, что в нём от порядка ничего не зависит, т.к. ты вызываешь две взаимно коммутативные операции.
Кстати, ты сам-то сможешь сказать, не запуская программу что произойдёт, если добавить третью строчку? Сколько и чего будет выведено на консоль?

ВВ>Я тебе дал пример — действие нужно выполнять *пошагово*. Мы не знаем — нужно ли нам проходить по всей последовательности. Пользователь жамкнет Next, пойдем дальше. Нет, так нет.

Ты, наверное, не понимаешь, что такое "конкретный пример". Пример "есть какое-то действие, которое нужно выполнять по какому-то условию" — абстрактный.
Ок, пусть у нас будет, к примеру, замена подстрок в тексте. Мы хотим перед заменой спросить у человека, надо ли заменять. Твой форич не делает того, чего нужно, потому что он будет сначала заменять, а потом — спрашивать.

ВВ>А куда стандартная делась?

Ты меня спросил, как я себе представляю ленивый Aggregate — я ответил. Я не виноват, что моя фантазия побогаче.
ВВ>Или теперь ленивость уже не является таким важным признаком?
Ленивость — является важным. Там, где можно лениво — лучше лениво.

ВВ>Основная цель ForEach — выполнить действие. Действие может иметь побочные эффекты.

Гм. Действие — и есть побочные эффекты. Действие без побочных эффектов = это хлопок одной ладонью.

ВВ>Да, пусть вероятность наличия побочных эффектов в данном действии 99 к 1 — но мы же не вероятность обсуждаем, а дизайн?

Дело не в вероятности. Вероятность отсутствия побочных эффектов здесь =0.
ВВ>Пример "чистого" ForEach — валидация последовательности: элементы последовательности должны удовлетворять некоторому условию, если не удовлетворяют — генерируем исключение.
Многословный и малопонятный способ записать
if (!sequence.All(condition))
  throw new InvalidOperationException();
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: LINQ & Except
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.06.09 12:35
Оценка:
Здравствуйте, _FRED_, Вы писали:


_FR>(Кстати, ожешь показать пример метода, имеющего побочный эффект, но служащего не "только для получения" этого самого эффекта?

Любая функция агрегации принимающая как параметр Func<T,S> (при замыкании на переменную), может убивать двух зайцев
и солнце б утром не вставало, когда бы не было меня
Re[25]: LINQ & Except
От: _FRED_ Черногория
Дата: 26.06.09 09:01
Оценка:
Здравствуйте, IB, Вы писали:

_FR>>Как это можно понять? Так "чистота" (то есть отсутствие побочных эффектов) или "ещё как-то смысл кроме побочных эффектов" должны позволять решить, делать метод расширением или не делать?

IB>Так и понять, что критерием является именно чистота, но так как абсолютная чистота для C# (раз уж мы о нем говорим) пока вряд ли достижима, то речь идет о чистоте сценариев использования для которых этот метод предназначен.

Спасибо, наконец-то дошло. Тогда такой вопрос: cледующий метод будет "идеалогически верным" или нет?

public void ForEach<T>(this ICollection<T> source, Action<T> action) {
  foreach(T item in source) action(item);
}
Help will always be given at Hogwarts to those who ask for it.
Re[25]: LINQ & Except
От: _FRED_ Черногория
Дата: 26.06.09 09:03
Оценка:
Здравствуйте, Serginio1, Вы писали:

_FR>>(Кстати, ожешь показать пример метода, имеющего побочный эффект, но служащего не "только для получения" этого самого эффекта?

S>Любая функция агрегации принимающая как параметр Func<T,S> (при замыкании на переменную), может убивать двух зайцев

Меня интересовал такой метод, одной из целей которого "является достижение побочного эффекта". Вариант с замыканием — это просто хак.
Help will always be given at Hogwarts to those who ask for it.
Re[26]: LINQ & Except
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.06.09 15:23
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Меня интересовал такой метод, одной из целей которого "является достижение побочного эффекта". Вариант с замыканием — это просто хак.

С точки зрения функционального программирования Action<T> тоже не кошерно.
и солнце б утром не вставало, когда бы не было меня
Re[27]: LINQ & Except
От: _FRED_ Черногория
Дата: 29.06.09 09:36
Оценка:
Здравствуйте, IB, Вы писали:

_FR>>Спасибо, наконец-то дошло. Тогда такой вопрос: cледующий метод будет "идеалогически верным" или нет?

IB>На мой взгляд нет.

Ага, спасибо. Наверное, если бы ты был настроен дать более развёрнутый ответ, то, несомненно так и поступил бы. Поэтому больше вопросов нет.
Help will always be given at Hogwarts to those who ask for it.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.