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

ВВ>Под анонимом заходят, чтобы написать:
ВВ>1. Глупость
ВВ>2. Хамство
ВВ>3. Высказать свое мнение "несмотря ни на что", даже если оно противоречит "политике партии".
Даже тебе, не всегда хватает смелости сделать все это под своим ником..

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

IB>Даже тебе, не всегда хватает смелости сделать все это под своим ником..

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

Понял. Мешать не буду. Развлекайтесь.

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

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

А>пример некорректен.
Он более чем корректен. Он очень точно показывает место всех подобных методов.

A>потому что это принципиально другой foreach.
То есть, если foreach принципиально другой, то в extension methods не годится, а если не принципиально, то годится?
Критерий принципиальности можно узнать?

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

А>читай ветку внимательно
Да уж, приз самого внимательного читателя ты заработал. Тебя не затруднит показать, в каком месте тебе что-то навязали?

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

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

Здравствуйте, _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 уже есть. Лучше внести это в библиотеку, поставляемую в комплекте с языком.

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

ВВ>Так что все просто. Обычный 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.

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

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

IB>Он более чем корректен. Он очень точно показывает место всех подобных методов.
нет некорректен, он абсолютно ничего не показывает

A>>потому что это принципиально другой foreach.
IB>То есть, если foreach принципиально другой, то в extension methods не годится, а если не принципиально, то годится?
IB>Критерий принципиальности можно узнать?
ну это элементарно, ознакомься что ли с этой библиотекой, потом сравни с, ну хотя бы, List.ForEach

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

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

_FR>>Какое? Этим местом является метод-расширение для IEnumerable или что-то ещё?
IB>Тебе в восьмой раз повторить?

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

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

Я этот вопрос уже в четвёртый раз задаю, а ответа не вижу

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

Чувак, на самом деле их точка зрения сейчас более или менее сформировалась и стала понятной. Я бы ее сформулировал так:
Исходя из того, что

1) IEnumerable предоставляет собой read-only forward-only модель работы с последовательностью, и
2) LINQ реализован в качестве методов расширений для IEnumerable

все последующие расширения для IEnumerable должны следовать "стилю" LINQ (а может быть, даже будут считаться своего рода "расширением" linq2objects).

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

Здравствуйте, 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<>

Может или нет?

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


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

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

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

Здравствуйте, <Аноним>, Вы писали:
А>я не Василий , но ты можешь звать меня Хозяин (с большой буквы пожалуйста)
Сразу после твоей регистрации под этим ником сие будет выполняться автоматически.

А>пример некорректен. потому что это принципиально другой foreach. именно поэтому он у них в своем статическом классе название которого отражает суть обработки.
А зачем тебе "принципиально такой же" foreach? Если твой тоже "принципиально другой", то по тем же соображениям он должен быть "в своем статическом классе название которого отражает суть обработки".

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

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

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

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

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

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

Здравствуйте, 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>Ничего странного. Фаулер пишет пургу, а Липперт — рулит. Тут как бы не личность первична, а её плоды.

А где Липперт-то рулит, а? Человек, имеющий отношение к языку, в котором лямбды реализованы поверх замыканий, у меня, ты знаешь, как-то автоматически не вызывает большого доверия.

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

А>>пример некорректен. потому что это принципиально другой foreach. именно поэтому он у них в своем статическом классе название которого отражает суть обработки.
S> А зачем тебе "принципиально такой же" foreach? Если твой тоже "принципиально другой", то по тем же соображениям он должен быть "в своем статическом классе название которого отражает суть обработки".
принципиально другой означает, что вообще будет работать иначе — а распараллеливание может внести кучу особенностей которые нужно учитывать при использовании таких вот ForEach. я же говорю о другом способе обработки (более оптимальном что ли) в зависимости от последоватености, здесь становится явно видно, что запускается ForEach этой конкретной последователности реализация этой конкретики может быть сделана в будущем. да и вообще все лаконично и законченно в таком вызове

з.ы. удивился, что есть люди с подписью rsdn, в топике, которые не хамят

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

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

Это же не уголовный кодекс, это рекомендация. Не стоит создавать методов расширения IEnumerable<> целью которых является получение побочных эффектов. Это полезно как присвоение идентификаторам говорящих имен, и почти также как объявление readonly, const и private. Если не следовать этим правилам код будет работать точно также, но сопровождаться намного дороже.

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

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

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

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

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

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

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

ВВ>Пример "чистого" ForEach — валидация последовательности: элементы последовательности должны удовлетворять некоторому условию, если не удовлетворяют — генерируем исключение.

Для этого есть более понятный Any()

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

А>нет некорректен, он абсолютно ничего не показывает
А>ну это элементарно, ознакомься что ли с этой библиотекой, потом сравни с, ну хотя бы, List.ForEach
А>ты забыл сказать пожалуйста, дурачок
То есть, по делу сказать нечего? Я так и думал, развлекайся дальше..

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

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

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

_FR>Я этот вопрос уже в четвёртый раз задаю, а ответа не вижу

Критерии extension methds для IEnumerable были сформулированы еще в блоге Липперта:
"Не стоит делать extension method для IEnumerable, единственным смыслом которого будет достижение побочных эффектов"
ForEach как раз ровно такой и есть.