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[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
От: 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[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[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[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[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[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
От: 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[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[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ледующий метод будет "идеалогически верным" или нет?

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